# Welcome Welcome to YuDash documentation. [YuDash ](https://docs.yudash.com/www.yudash.com)is an Indian startup working in Industrial IoT products and solutions, with focus on IoT Gateways and Data Loggers.

IIoT (Industrial IoT) is a fairly wide topic involving data flow from field instruments, network layers to various cloud/edge servers. We have developed a stack which our team has termed as **YuDash IIoT Stack**. It's just a simple way to explain YuDash product features to our users (to ourselves!). Most of our documentation, integration guides and APIs will be covering some part of this stack. ## YuDash IIoT Stack

The documentation is organized in the following manner: ## YuDash IoT Devices YuDash primarily focuses on IoT devices (Gateways, Data Loggers). This section comprises of user manuals of IoT devices offered by YuDash. **YuDash LYNX** is our popular product. [LYNX User Manual](/yudash-iot-devices/lynx-user-manual) covers all aspects of using the product. It covers aspects of various industrial protocols. ## Device to Cloud YuDash IoT gateways (LYNX and ZENYX) can be easily integrated with any IoT platform on cloud and on-premise. This is enabled by support of multiple [Cloud Protocols](/device-to-cloud-api/cloud-protocols) and [Payload Formats](/device-to-cloud-api/payload-formats). Documentation on various [Network connectivity](/device-to-cloud-api/network-connectivity) options is also covered. ## Integration Guides The [IoT platform Integration Guide](/integration-guides/iot-platform-integration) covers seamless use of YuDash products with various global IoT platforms. IoT gateway has to talk to plethora of industrial instruments, sensors and equipment. Needless to say, this should be simple and easy. Integration with various [Industrial Instruments](/integration-guides/industrial-instruments) is documented. {% hint style="info" %} Please mail to if you find anything missing or erroneous in the document. Our team will be glad to add new instrument integration guide. {% endhint %} ## Use Cases Any technology, be it IIoT or any other, needs to solve a problem and generate ROI. The [Use Cases](#use-cases) section covers the IIoT applications developed by YuDash team or our esteemed customers. ## Product Catalogs **YuDash LYNX** {% file src="/files/pWJlqemGrJlyKkyYSxB4" %} **YuDash ZENYX** {% file src="/files/S0PB2GMyAm9DpwvjX4kq" %} **YuDash QUBIX** {% file src="/files/QbK737tY1xWk0HXhpQir" %} **YuDash ONYX** {% file src="/files/Av4909SrVBiFiRuP1abZ" %} **YuDash Setu** {% file src="/files/r6iIXhyTWRxxk6nXV2Cr" %} **YuDash for Environment Monitoring** {% file src="/files/Erb3yyhAS8WUb8H7sUFN" %} **YuDash for Weather Monitoring** {% file src="/files/s6Ojv2wawiMbvhX3sBY8" %} **YuDash IIoT Solutions** {% file src="/files/wXp5MRoEwumi0DL23DSm" %} # LYNX User Manual ## YuDash LYNX Overview YuDash LYNX series of Industrial IoT Gateways and Data Loggers provides a flexible cloud connectivity to industrial and environmental instruments, PLC/HMIs and equipment. It supports a host of industrial protocols, including Modbus RS485, MODBUS TCP/IP, analog inputs and I2C sensors. LYNX acts as Modbus master and reads up to 96 parameters across 16 Modbus slaves. Four analog channels (0-20/4-20mA) are supported. LYNX can connect to network (LAN or Cloud) through 4G/LTE, Ethernet and Wi Fi. LYNX communicates with IoT platforms through MQTT, HTTP and FTP protocols. Effectively, any IoT platform can be connected using inbuilt JSON payload format library. It also has payload generator engine to support custom text and CSV payload. LYNX can be easily configured in web-browser through laptop or mobile phone. On-device OLED display shows running status and simplifies deployment and debugging. Advanced features like input data scaling, two-way communication through Modbus-write, low power variants are available to support various use-cases. JSON based configuration backup and restoration aids deployment at scale. Product variants with subset of features are available for a cost-effective IoT gateway depending on application.

### Key Features * Easy to configure gateway over local Wi-Fi * Configurable through JSON file for mass deployments * On-device OLED for status and fault detection * Data Scaling feature to map inputs to required process parameters * Configurable looping cycles (10 second to 1 day). * Auto Reboot options * Low Power version with deep-sleep * Network failure handler: local storage and back-filling ### **Technical Specifications** * Input Power: 24V DC Standard (12-28V) * DIN Rail / Wall mounting * 94 x 90 x 35mm * ABS plastic enclosure with IP30 rating * On device OLED display * Weight: 210 grams approx. * SMA female connector for external 4G/LTE Antenna * Micro SIM card slot ### **Cloud Connectivity Options** * 4G/LTE * Ethernet * Wi-Fi ### **Supported Industrial Protocols:** * Modbus RS485 * Modbus TCP/IP * Analog Inputs * I2C Sensors * HTML Parser ### **Cloud Protocols:** * MQTT * HTTPS (REST API) * FTP **Payload Formats** * JSON: LYNX has multiple inbuilt JSON payload formats to support various IoT platforms. * TEXT: Inbuilt payload generator for custom text and CSV formats. ## LYNX Product Variants ### YuDash LYNX IoT Gateway Part Numbers

Part No	4G/LTE	Ethernet	RS485	RTC	I2C	Low Power
LYNX40	true	false	true	true	true	false
LYNX41	false	true	true	true	true	false
LYNX42	true	true	true	true	true	false
LYNX45	true	false	true	true	true	true

**Wi-Fi network connectivity common across all IoT Gateways.** ### YuDash LYNX Data Loggers Part Numbers

Part No	4G/LTE	Ethernet	RTC	SD card	Analog	I2C
LYNX48	true	true	true	true	true	true
LYNX49	false	true	true	true	true	true

**Common Features across all data loggers:** * **Wi-Fi Network Connectivity** * **RS485 Modbus** * **Network Failure Handler** ## User Manual Overview The LYNX user manual covers the following sections: * LYNX Terminals, connections and wiring * LYNX Configuration for various aspects: * Connecting LYNX to various networks * Interfacing LYNX with various field instruments * Configuring LYNX with various cloud platforms {% hint style="info" %} As the LYNX UI is continuously evolving, some of interfaces in your product may be slightly different from the ones in manual. {% endhint %} # Terminals and Wiring ## Introduction ## YuDash LYNX Terminals Top view of LYNX (without terminal cover)

Terminal view of LYNX (There are 2 rows of 13 terminals on each row)

## LYNX Power Connection LYNX is powered by 24V External Supply (red and black wire in the image below).

LYNX after being powered by 24V DC supply

## LYNX Peripheral Inputs Besides wire terminals, LYNX has various input connections, as represented below:

{% hint style="info" %} Availability of given interface in LYNX depends on the product variant. Please refer to[ LYNX product variants](/yudash-iot-devices/lynx-user-manual#lynxpartnumbers). {% endhint %} ## Ethernet LAN port

LYNX RJ45 port connected with Ethernet cable

## 4G/LTE SIM card Slot

## 4G/LTE Antenna Connection

LYNX with Rubberduck antenna. DIN rail mounted.

LYNX with wired magnetic Antenna. The antenna can be mounted outside the panel

## SD card Slot

## LYNX Terminal Wiring Examples ## Modbus RS485 Wiring Modbus (A and B) terminals of LYNX are connected to yellow and green wires respectively. 12/24V DC +/- power terminals are connected to red and black wires respectively.

# LYNX Configuration LYNX is configured through Wi-Fi using a laptop, tablet or mobile phone. There is no need to install any software or LAN wiring. {% hint style="info" %} LYNX now also supports configuration through LAN cable. Please refer to [Device Configuration](/dc/dc1) section. {% endhint %} Following are 3 simple steps to initiate LYNX configuration. **Step 1**: On LYNX bootup, the device waits for 5 seconds for user to start configuration server. The LYNX screen shows the following message (with countdown from 5 to 0):

During the countdown, short press the Config button (connected with SW GND top right terminal) to start the configuration server.

{% hint style="info" %} Do not long press the Config Button. Just push and release! {% endhint %} **Step 2:** Once the button is pressed, the device will enter in AP (Access Point) mode, meaning a Wi-Fi network will be broadcasted. The Wi-Fi SSID name and password are displayed on the LYNX screen. Connect the laptop to the given Wi-Fi.

Details of Wi-Fi created by LYNX are displayed on the LYNX screen and are as follows: 1. Wi-Fi SSID: ***yu10000492*** 2. Wi-Fi password: **12345678** 3. LYNX IP address: ***192.168.4.1*** {% hint style="info" %} **Troubleshooting Guide to connect to LYNX Wi-Fi** 1\) In some cases, Wi-Fi may be shown as "Open network". In this case, no need to enter Wi-Fi password. 2\) At times, the Wi-Fi setting on laptop may be showing "Connecting.." instead of "Connected to Wi-Fi" after LYNX Wi-Fi is selected. No need worry. Please open the Configuration URL (192.168.4.1) on laptop. It should simply open. 3\) In case of further trouble, please "Forget" any previously stored Wi-Fi names linked to LYNX. {% endhint %} **Step 3:** This is how LYNX configuration page looks like on laptop.

{% hint style="info" %} While laptop is connected to local Wi-Fi of LYNX, internet will not be accessible on the laptop. {% endhint %} LYNX will keep the configuration server running for up to 5 minutes on inactivity. All LYNX configuration will be done through this page as covered in subsequent sections. **Following video explains the complete procedure to start LYNX Configuration page** {% embed url="" %} ### ### LYNX Configuration Sections Following are the main sections in YuDash LYNX Configuration page: 1. **LYNX Device Information**: This is read-only section with LYNX model, hardware and firmware information. 2. **Network Setting**: This section is used to configure network connectivity of LYNX. Depending on model, LYNX can connect to internet through (a) 4G/LTE (SIM card) (b) Wi-Fi or (c) Ethernet LAN. It can also work in offline mode (when it is used for local storage or display only). 3. **LYNX Settings**: This is main section in which all features of LYNX are configured. It includes (a) Data send frequency, (b) Feature enable/disable (given industrial protocol) and (c) Custom cloud selection. Detailed configuration of a given feature is done in subsequent sections. ### LYNX Device Information **LYNX Device Information** read-only section with LYNX model with following information:

1. **Part No**: The device part number. 2. **Serial No**: Unique serial number of the device. 3. **Hardware Ver**: Hardware PCB version. 4. **Firmware Ver**: LYNX firmware version. 5. **Default Device Settings**: By default, each YuDash LYNX gateway is pre-configured with "YuDash Cloud". Effectively, given LYNX IoT gateway is mapped to a unique "device" on YuDash IoT platform. 6. **Get Mac Address** **Button**: This button fetches the MAC address of the LYNX IoT gateway. This MAC address is used for both Wi-Fi and Ethernet. {% hint style="info" %} MAC address of LYNX is required for use of IoT gateway in enterprise networks for security purpose. The MAC address is required for "White Listing" of the gateway. In some cases, MAC address and static IP of device is tightly coupled to gain access to the network. {% endhint %} # Network Settings **LYNX Network Settings** section deals with connection of LYNX with the network. It is typically internet or local LAN in some cases. Depending on model, LYNX supports the following options to connect to network: 1. **Wi-Fi**: LYNX connects to a Wi-Fi network (router) to access the internet/local LAN. All models of LYNX support connection to internet through Wi-Fi. 2. **Ethernet**: LYNX connects to internet through Ethernet (RJ45 jack). * By default, it assumes DHCP connection (in which IP address is assigned by router). In this case, no further change in setting is needed. * LYNX also supports static IP address configuration under advanced Ethernet settings. 3. **4G/LTE (Sim card)**: LYNX connects to internet through 4G/LTE SIM card. * Support of all 4G networks, independent of carriers. LYNX has been tested with all carriers in India. * Option to provide carrier APN. Though, this is not critical. * Support of external antenna for in-panel applications. 4. **None (Offline)**: LYNX is not being connected to any network and is being used as display unit. This mode is also used for debugging purpose.

## Read and Write Network Settings 1. **Click on "Read Network Settings"** button. The network settings will be populated in configuration page from LYNX. It may take 1-2 seconds for this process.

2. Various network Settings are populated in the configuration page from LYNX. Apply required changes in given section.

3\. After all the changes are completed, click on **Write Network Settings** button. This will update the network settings in the LYNX. A popup is displayed. After clicking on Write Network Settings, wait for 2-3 seconds for update.

4\. Click on **Reboot LYNX** button to reboot the LYNX. Alternately, LYNX can be power cycled. LYNX will use updated Network Settings after reboot. During initial runs, it is better to cross check whether settings have been updated in LYNX after the reboot.

## Selection of Network Settings in LYNX **Network Selection** radio button is used to select a given type of network. Details of each network type is covered in following sections.

Complete steps of Network Selection are covered in the video below: {% embed url="" %} ## Updating Wi-Fi Settings in YuDash LYNX 1. To Change the Wi-Fi settings, click on show password checkbox. Update the Wi-Fi SSID name and password in given text boxes.

2. In the above settings, the SSID#1 has been changed from yudashdemo to my\_test\_1 and password has been updated. Similarly, WIFI SSID#2 has been changed to mytest2.

### **LYNX WiFi Features and Specifications** 1. LYNX supports DHCP Wi-fi connection only. 2. LYNX supports 2.4GHz Wi-Fi only. 5GHz Wi-Fi networks are not supported. 3. LYNX supports DHCP Wi-fi connection only (IP address issued by Wi-Fi router). 4. For on-premise solutions, Wi-Fi with local LAN access can be used (without any need for internet connection). 5. LYNX has in-built Wi-Fi antenna. There is no provision of external Wi-Fi antenna. 6. There is provision to provide two Wi-Fi networks. By default, LYNX attempts connection to first Wi-Fi (Wi-Fi SSID#1 and Wi-Fi Password). In case it is not connected, it will attempt to connect to (Wi-Fi SSID#2). It is not mandatory to fill both Wi-Fi settings. {% hint style="info" %} **YuDash LYNX WiFi Trouble Shooting Guide** Please consider the following in case you are facing Wi-Fi connection issues: 1. Check special characters and space in Wi-Fi SSID and password entry boxes. 2. Create a simple SSID name and password using mobile phone and first connect to that Wi-Fi. {% endhint %} ## Updating 4G/SIM LTE Settings in LYNX When 4G/LTE sim card is selected, LYNX uses 4G connection for connecting to internet. In general, there are no settings required. * There is option to provide APN (Access Point Name) which can be selected based on carrier. In our observation, it is not mandatory to update this. * The option 4G TimeOut (sec) is the time LYNX will attempt to connect to the SIM network. Depending on network strength, it takes up to \~20 seconds for LYNX modem to connect to network. This setting can be tweaked in case of connectivity issues.

{% embed url="" %} ## Updating Ethernet Settings in LYNX Ethernet port can be used to connect to cloud (or on-premise server). This is enabled by selecting Ethernet in Network Settings as below.

Ethernet supports dynamic IP (DHCP) and static IP option. By default, dynamic IP is assumed in which IP address is assigned by local LAN router. In this case, there is no further configuration in this section. This is most common use-case for most of the applications. For assigning static IP to LYNX for network connection, please refer to [Ethernet Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/ethernet-settings) section. {% hint style="info" %} For using ethernet port for network connectivity, there is no need to enable Ethernet within LYNX settings. Just selection of Ethernet in Network Selection is sufficient. {% endhint %} Following is sample connection of Ethernet RJ45 jack connected to LYNX:

### **LYNX display during Ethernet Setup**

# LYNX Settings This is the main LYNX setting section in which all device configurations of LYNX are done. Primary LYNX settings include: * Which data to read and process and the instruments to read along with their protocol settings (Modbus/RS485, Analog, Modbus/TCP). * Where to send data (Cloud/LAN server). It may be default YuDash IoT platform or customer's cloud server. * Enabling, disabling and configuring specific features of LYNX (depending on LYNX model. ## Reading and Updating LYNX Settings 1. Click on **Read LYNX Config** button. This will fetch LYNX settings from the LYNX.

2. After this step, complete LYNX settings are populated. In above example, the loop delay of 60 seconds is set. Modbus/RS485 is enabled and default YuDash cloud is used.

3. In this example, Loop Delay has been changed to 120 seconds under General Settings.

4\. After making changes, click on **Update and Preview** button. This step checks the validity of all settings before writing to LYNX.

5\. Click on **Write LYNX Config** button. This will write updated settings in LYNX. A popup is displayed that settings have been sent to LYNX.

6\. After all changes are completed, reboot LYNX by clicking **Reboot LYNX** button under Network Settings.

## General Settings This section has the following components: ### **Loop Delay (Sec)**: This the cycle time (in seconds) of main loop of LYNX. Following is the main operation cycle of LYNX: 1. Read the data from given set of instruments. 2. Process and send the data to given cloud. 3. Wait (Sleep) for given cycle to complete. During this wait time, LYNX performs background task as specific in the settings. Loop Delay defines the frequency of data processing of LYNX. If Loop Delay is specified as 60 seconds (1 minute), LYNX will send process data to IoT platform every 1 minute. {% embed url="" %} Notes on Selection of Loop Delay * The loop delay has to be set by customer based on given application and required data frequency on cloud. Please note that there is cost (bandwidth, storage) involved with each data point. Typically, all IoT platform (including YuDash) have data plans depending on volume (number and frequency) of data points. * The cycle-time of LYNX is subject to time taken in reading instruments and network connectivity. Typically, instrument reads (on Modbus or analog) are instantaneous, but the read cycle may be prolonged in case of invalid registers or settings, causing timeouts and retrials. * In case, the loop delay is set to be too low, which is less than processing cycle time, there will not be any wait in LYNX. * For typical cloud applications loop delay of 2-5 minutes (120 to 600) will be suitable to capture real-world parameters. ### **Device Name** A device name (string) is provided by customer. It is displayed on OLED during running. This is only for information, traceability purpose. This is not used in any data processing. ## Features Settings This section enables/disables a given feature (protocols) of LYNX using the checkbox. Each protocol is configured in subsequent sections. Please note following: * It is ok to configure a given feature and still keep it disabled in this section. * Even though all features may be displayed in configuration page, availability of given feature depends on LYNX model. ### Cloud/Network Server Settings This section defines the server (cloud or local LAN) on which data has to be sent. By default, LYNX will send data to YuDash cloud (when "Use YuDash cloud" is checked).

Besides YuDash cloud, YuDash LYNX can send data on HTTP, MQTT and FTP servers. The cloud servers are configured in **Custom Cloud Server Settings** in which all credentials are specified. * YuDash supports variety of JSON payload settings. * It supports majority of popular IoT platforms which can be used in a plug and play manner. * Similar to field instrument settings, it is ok to populate settings of various network protocols in LYNX. Refer to [YuDash Device to Cloud API](/device-to-cloud-api/yudash-iiot-stack) section to configure LYNX with 3rd party servers. ## Save/Load LYNX Settings LYNX provides an easy backup and restoration of LYNX configuration settings. After initial settings, one can "download" the settings in a text (json) file on laptop/mobile. Let's call the file **lynx.json**. This lynx.json can be later restored (re-loaded) in LYNX to overwrite all LYNX settings. The network settings remain unaffected in this backup and restore. Network Settings have to be updated manually only. For some of advances features, the lynx.json can be edited directly in JSON format. #### **Saving (Downloading) LYNX Settings on local Laptop/PC as JSON text file.** {% embed url="" %} #### **Loading LYNX Settings from JSON in local laptop/PC.** {% embed url="" %} ## LYNX Features LYNX supports various integration with various industrial protocols and cloud platforms. Each feature is covered under a different section in configuration page. It is scrollable from left bar. In most of cases, each section (or its sub-section) has an open, read and update button. Finally, one needs to do an "Update and Preview" and Write to LYNX as explained above. For first time users, it is recommended to write to LYNX, power cycle the device and verify that given changes were actually updated in device. Following are the list of sections in Configuration page. These are documented as part of LYNX manual or separate integration guides. #### [Modbus RS485 Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-rs485) #### [Analog Input Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/analog-inputs) #### [DataScale Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/data-scaling) #### [Advance Feature Settings](#advance-feature-settings) 1. RTC Settings 2. Network Failure Handler Settings 3. YuReCon Settings #### [Custom Cloud Server Settings](/device-to-cloud-api/cloud-protocols) #### [Payload Settings](/device-to-cloud-api/payload-formats) #### [Ethernet Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/ethernet-settings) #### [Modbus TCP Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-tcp-ip) #### HTML Parser Settings #### SNMP Settings #### Extension Settings 1. Modbus RS485 Channel#2 #### 4G Modem Diagnostics Each feature is accessible from The feature details are covered in subsequent sections * # Modbus RS485 Modbus/RS485 is a popular serial protocol to read various sensors. YuDash LYNX is being used to read a variety of instruments, sensors and PLCs for various applications. LYNX provides easy to configure approach for reading field Modbus instruments. Following are the key information points required for a successful read of instrument through Modbus: 1. Baudrate 2. Data Bits, Parity and Stop Bit 3. Slave ID of instrument 4. Modbus register information to read: 1. Modbus register numbers and types) 2. Modbus register data types (Size: integer/float/real. Byte swapping information: LSB/MSB etc.) 5. Modbus register address. {% hint style="info" %} Additional Modbus documentation available in YuDash Device Features and APIs: a) [Modbus RS485](/dc/df/modbus) b) [Modbus-Poll Tutorial](/dc/df/modbus/modbus-poll-tutorial) c) [Modbus Topologies](/device-to-cloud-api/industrial-protocols/modbus) {% endhint %} ## Modbus Register Mapping in YuDash LYNX. Following four inputs have to be provided for processing of each Modbus register in YuDash LYNX: 1\) **Variable Name:** YuDash LYNX reads a given Modbus register and stores it in a variable. This is the user defined string, which will be sent to IoT platform/server along with the process values. For sending to YuDash cloud, the variable names should be all small letters without any blank spaces. Sample variable name: **volt1 temperature\_celcius amp\_01 amp\_02 machine\_status\_flag** 2\) **Register Number:** The register types/function codes of Modbus are defined by register numbers. User has to specify complete **#Register No.** in Modbus register section. Following is the available range of registers: | Function Code | Registers | Range | | ------------- | --------------------- | ----------- | | **1** | **COIL STATUS** | 0-9990 | | **2** | **INPUT STATUS** | 10000-19999 | | **4** | **INPUT REGISTERS** | 30000-39999 | | **3** | **HOLDING REGISTERS** | 40000-49999 | {% hint style="info" %} Important Note: LYNX uses base-0 register addressing (starting with 40000). OEM instrument manual uses both base-0 or base-1 registers, so that they have to checked accordingly. The MODSCAN uses base 1 register addressing (starting with 40001). So, after MODSCAN registers are identified, you have to enter register as one less than the MODSCAN register. {% endhint %} 3\) **Type**: The data type of Modbus registers are specified in data **Type** code in MODUS register settings. Following are the register type codes:

Type	Description	No. of Registers read	Byte Sequence
1	SIGNED INTEGER	1
2 or 20	Floating Point (LSB first)	2	CDAB
21	Floating Point (MSB first)	2	ABCD
22	32bit Integer (LSB first)	2	CDAB
23	32bit Integer (MSB first)	2	ABCD
24	32bit Unsigned Integer (LSB first)	2	CDAB
25	32bit Unsigned Integer (MSB first)	2	ABCD
11	Bit pattern Extraction	1

{% hint style="info" %} LYNX also supports byte swapping for 32 bit registers. For these special case, we have to use 3 digit Type (by adding a suffix 1 to original type). It will enable byte swapping with same data type as corresponding 2 digit code: \ **201, 221, 241**: **DCBA** \ **211, 231, 251**: **BADC** *Note: Support of code 24, 25 and 3 digit types is available in firmware V3.6 onwards.* {% endhint %} YuDash IoT devices also support various 64 bit data types as IEEE-754 Floating-Point numbers and also 64 bit signed integer. For 64 bit data types, 4 modbus registers are read. We are not using terminology of LSB and MSB as there are various nomenclatures. We effectively support all swapping at 16bit register . We are calling them P, Q, R, S (for each 16 bit modbus register). This is similar to ABCD were bytes. *Note: 64 bit data type is available in firmware V3.6 onwards.* Following are possible combinations:

Type	Sequence	Type	Sequence	Data Type
4 or 40	RSPQ	401	SRQP	Float 64
41	PQRS	411	QPSR	Float 64
42	RSPQ	421	SRQP	Int 64
43	PQRS	431	QPSR	Int 64

{% hint style="info" %} By default, all values from YuDash IoT devices are converted to 32 bit floating point numbers. So, while we can read larger 64 bit values, there may be data precision loss or possibly overflow while processing large number 32 bit integer or 64 bit data types. Use of factor (see below) may be useful to handle cases of data overflow. {% endhint %} 4\) **Factor**: LYNX provides option to post process register value after reading of inputs. The register value is divided by the value provided in Factor. By default, Factor of 1 used . Typically, Factor of 10 or 100 may be used in cases when Modbus registers are integer representations in multiple. For example, if the voltage of 234.6 is represented as integer of 2346 in Modbus register, factor of 10 can be used. With this factor, LYNX will read 2346 integer value, divide by 10 and send 234.6 on the cloud platform. This helps in receiving values on cloud which map to values seen on display. In many cases, 100X value is used in integer form. {% hint style="info" %} In most of industrial applications, MODSCAN (or similar) software is used to validate the Modbus settings. In case of any troubleshooting, we strongly suggest to validate the communication through MODSCAN. Our tutorial explains the mapping in reference of MODSCAN to LYNX settings. {% endhint %} ## Modbus/RS485 interfacing example To explain Modbus/RS485 mapping in LYNX, we will interface it with a single phase energy meter to read its voltage and frequency. 1. Selec make EM2M is used to interface with MODSCAN software followed by YuDash LYNX.

2. Energy Meter MODUBUS settings checked in MODSCAN software.

3. Voltage and Frequency values test-read in MODSCAN software and co-related with datasheet values.

4. Corresponding settings updated in YuDash LYNX Modbus/RS485 section.

Following video explains the steps for updating Modbus/RS485 settings in LYNX: {% embed url="" %} # Analog Inputs Few variants of LYNX support direct analog read inputs. LYNX supports 8 channels of 0-20mA read. The terminals A1 to A8 terminals are available for 8 channels of analog. In most of industrial applications, 4-20mA values are mapped to given process values. LYNX has advanced data scaling features to handle process values of different applications. While user can perform scaling within Analog Inputs, we recommend using generic [**Data Scaling**](/yudash-iot-devices/lynx-user-manual/lynx-settings/data-scaling) section of LYNX for analog data interpolation. ## Analog Input Settings **Analog Inputs Settings** has 4 buttons for 4 channels, which can be enabled/disabled and configured independently. **Analog Inputs** feature has to be enabled (check box) in LYNX Feature Settings to process analog channels.

## Analog Input Configuration 1. A given analog channel (A1 to A8) has to be enabled by clicking the checkbox. 2. Output values ranges \[**minOutVal,** **maxOutVal]:** These are the output value ranges (minimum and maximum) of the analog module. These can be used for basic linear scaling of inputs. If set to \[0, 100], the analog output will be 0 to 100 for given input mA range (0-20). 3. Input current range \[**minmA, maxmA**]: This is the range of input milli Amperes to be read. For most of the applications, this should be 0 and 20. For instrument calibration, the maxmA may be set lower than 20 (say 19.8) to map to real-world process values. 4. **varName**: The variable name in which output value will be stored. 5. **varName2**: For analog inputs, this is optional additional variable name in which analog output will be stored. Keep it blank unless necessary. 6. **varFactor**: The output value will be multiplied by the varFactor. We will keep it 1.

### Analog Input Source Wiring Connection of a current source (0-20mA or 4-20mA) to YuDash LYNX A1 terminal.

Sample connection of 4 analog sources connected to LYNX. This is a typical scenario of LYNX connected to environmental sensors with multiple analog outputs.

# Data Scaling This is a data-processing layer for scaling of input data. This can be applied to any variable (read by Modbus, analog or any sensors). Following are the basic steps to use this feature: 1. Click on Open DataScale Settings button. It will open table with dummy values.

2. Click on Read DataScale Settings button. It will update the table with actual DataScaling settings for a given variable (if present).

3. Update the variable names and scaling. It is mandatory to have Enable Scaling Flag ticked to get a given scaling function enabled.

3. Click on **UpdateDataScale** Settings button to update the data scaling features. ### Data Scaling Processing For a given variable, following Data Scale function is applied: a) The variable is scaled using values provided in the Input Range (Minimum and Maximum) to the Out Range (Minimum and Maximum). b) After the above step, the output values are clipped to be within range of Minimum Cutoff Limit and Maximum Cutoff Limit values. It is not mandatory that variable should be within Input Range value. Input and Output Range values are used to create the slope and offset (y=mx+c) to derive at output value. Finally, the output values can be clipped using Cutoff Limit values. ### **Explanation of DataScale function in representative example:**

\ 1\) analog1\_celcius: Input values 0 to 20 (mA) will be scaled to -5 to 55. This example uses an analog temperature. The output values are clipped to -5 to 55. Just in case analog value becomes >20 or <0 due to calibration error, the output will always be in range -5 to 55. 2\) analog2\_aox: This example represents an air analyzer sensor, in which 4-20mA range represents value of 0 to 600. In case the sensor is OFF (or not working), the input values of 0mA (any value less than 4.0) will first be calculated as a -ve value. But it will be clipped to be in range of 0 to 600 using Cutoff Limits. 3\) analog3\_freq: This represents an AC drive which gives frequency output in 0-20mA range. However, as it was identified during calibration that actual mA output of AC drive was only 19.8 at full 50Hz frequency, we scale 0-19.8 input to 0-50Hz and apply cutoffs. 4\) analog4\_humidity: A sample humidity scaling function. In this case, the error cases are identified using out-of-range limits (-1 to 101) to represent error scenarios. Scaling functions applied to 4 variables (as defined in analog section). **Enable Scaling Flag** has been ticked to have scaling function enabled. # Advance Feature Settings The **Advance Feature Settings** contains a group of features for fine tuning of LYNX for specific use-cases.

## Data Points per Packet This (**dpPerPacket**) is a configurable parameter for deciding the data points to be pushed to cloud in a given packet. To understand this, let's first go through a typical run cycle of LYNX. 1\) LYNX reads all field instruments and sensors as defined in **Feature Settings** and stores them in local variable. Subsequently, data scaling may be applied on inputs. Depending on the settings, LYNX may read 1, 5 or even 100+ variables in a given cycle. Now, these variables have to be packaged in a payload (packet) and sent to cloud. Depending on protocol being, server capability, it may or may not be possible to send all data points in a single API call to cloud. dpPerPacket decides how many data points (variabled) should be packed together in a single payload packet and sent to cloud. As an example, let's assume LYNX is reading 10 MODBUS registers and 3 analog inputs (total 13 variables).

Data Points Per Packet	Remark
1	Each variable will be sent as independent packet. So, there will be 13 API calls based on cloud protocol (MQTT, HTTP etc)
5	There will be 3 cloud push with packets of 5, 5 and 3 variable each.
16	All 13 variables will packed together in a single packet. It is ok to set dpPerPacket to a number higher than variables being read.

**Considerations for settings of dpPerPacket** Depending on cloud server, the API may be accepting just one value at a time, in which case, dpPerPacket of 1 may be required. This setting typically consumes more bandwidth. In case there are quite many variables (say 100), some of the protocols like MQTT (or due to server restrictions), all variables cannot be sent together. So, packets of reasonable size (say, 16 or 20 data points per packet) may need to be created as per use-case. In case of CSV, Text File push through HTTP or FTP, it may be mandatory that ALL data points have to be processed together only. So, in this case, dpPerPacket has to be set to a value higher than number of data points being read. For example, to read 13 data points across industrial sensors, dpPerPacket has to be set to 16. {% hint style="success" %} LYNX displays data point per packet on screen as below: {% endhint %}

## Auto Reboot Cycle In some use-cases, it is required (and advisable) that LYNX is rebooted periodically to avoid the possibility of hanging. The parameter, **Auto Reboot Cycle**, defines **number of main loop cycles** LYNX will run before it reboots itself. Please note that this is not clock time. So, this parameter has to be set based on loopDelay being used and preferred frequency of auto-reboot. For example, if loopDelay is set to 300 seconds (5 minutes) and AutoRebootCycle is set to 36. LYNX will reboot itself after approx 3 hours (5 minutes x 36 = 180 minutes). By default, auto-reboot Cycle is set to 0, which means LYNX will not auto-reboot. ## Enable Debug This flag is used to enable or disable Debug output of LYNX for troubleshooting and development purpose. For most of the applications, it can be left as enabled. If you are trying to run LYNX with a very small loopDelay (to capture data at high rate), this flag should be disabled. ## RTC Settings As per the product variant, LYNX provides in-built clock (RTC) to maintain local time. RTC may be required in the following typical use-cases: * TimeStamp is required by server/protocol along with data points. * Data backfill in case of network loss. TimeStamp is stored in local storage along with timestamp tags. * Running LYNX in clock Time-Sync manner {% hint style="info" %} The LYNX IoT gateways without RTC cloud do not know or maintain current time. They are designed to send data at a given time interval. All data points are sent without time stamp. All latest IoT platform take present UTC time as per data received on server. {% endhint %} ### Enabling RTC RTC is enabled by check box **Enable RTC** {% hint style="warning" %} RTC check box should be enabled only for supported devices. Otherwise, LYNX may crash during RTC setup. {% endhint %} {% hint style="success" %} LYNX message after RTC setup {% endhint %}

## TimeSyncRun TimeSyncRun is advanced version of loop delay, to run LYNX in a time-sync manner. For example, suppose we want to send data to cloud at a 5 minute interval, synced with clock (10:00, 10:05, 10:10). To achieve this, TimeSyncRun is set to 5. It is different from using loopDelay of 300 seconds, where data is first sent on bootup and 5 minutes subsequently. So, you may receive data at clocktime 10:02, 10:07, etc., depending on when LYNX was booted. With TimeSyncRun, LYNX will send first data only when clock ticks to the given 5 minute time. {% hint style="info" %} The unit of TimeSyncRun is **minute**. So, we can run LYNX loops in multiple of minutes only, without further granularity. {% endhint %} Default value of TimeSyncRun is zero, and loopDelay is used for looping cycle. If TimeSynRun is 1 or higher (and RTC is working ok), it will be used. {% hint style="info" %} Due to any reason, if RTC is not working, then TimeSyncRun parameter will be ignored and loopDelay will be used. So, it is advisable to set loopDelay to value of TimeSyncRun\*60 (seconds). {% endhint %} {% hint style="success" %} LYNX displays local time and TimeSync information on OLED display. {% endhint %}

### Reading and Updating RTC Settings RTC setting for timesync and timezone is performed by Reading and Updating RTC Settings. ### **Clock Time Synchronization Mechanism** LYNX uses the following mechanism to sync clock at bootup, depending on network use. 1. 4G/LTE network: LYNX uses modem clock time as current local time. 2. Wi-Fi/Ethernet: LYNX takes time for NTP server at bootup. This can be enabled/disabled by checking "NTP Sync at Bootup". Default server of pool.ntp.org is used to get UTC time. It can be updated by NTP pool server entry. ### Time Zone Minutes Settings TimeZone Minutes is set as offset of local timezone from UTC. If local time is ahead of UTC, positive number has be given. For example, India is +5:30 time zone. So, TimeZoneMinute of 330 (minute is applicable). This parameter is used in the following time adjustments: When time is synchronized with NTP servers, Time Zone Minutes is used to derive local time. Based on selection of timeStamp format, UTC or local time may be used in payloads. When local time is taken from 4G modem, UTC time is derived Time Zone Minutes. {% hint style="info" %} Default Time Zone Minutes is taken as 330 (IST) if no value is given. {% endhint %} ### Daylight Savings At present, LYNX does not support Daylight saving adjustment. So, fixed TimeZone is applicable. Depending on network usage and server settings, timeStamp format should be selected. Please contact YuDash technical support to cover this use-case. We are looking for use-case and solution to handle Daylight Savings in a graceful manner. We will be pleased to discuss the requirement and suggestion in this regard. {% hint style="warning" %} LYNX does NOT support Daylight setting at present. {% endhint %} ## Network Failure Handler Settings LYNX Data logger variants support advanced network failure handlers to avoid data loss in case of network failure. In case there is a network failure, LYNX can store the payload in local storage which is back-filled in server. This is termed as NFH (Network Failure Handler) feature in LYNX. Following are the pre-requisites for NFH: 1. SD card should be connected and mounted in LYNX 2. RTC should be enabled and working. 3. TimeStamp setting in payload should be enabled. 4. The server should support and accept historical data points. Assuming that the above requirements are met and NFH is enabled, further behaviour is as follows: In case the cloud server is not accessible (due to potential network failure), LYNX tries to reconnect to network (4G, Ethernet, Wi-Fi). If not successful in the given attempts, it will enter **NFH** mode. In NFH mode, LYNX will store the payload in local storage as separate files (in pre-defined directory). LYNX will run for cycles as defined by **maximum NFH Runs** and then reboot. After reboot, it will again try to connect to network. If successful, it will send historical payloads along with current data points. The stored payload files are deleted after successful data push to cloud. If network connect fails at boot-up, it will again store local files for given NFH runs until next reboot. {% hint style="info" %} As network reconnect attempt may take 1-2 minutes (for 4G/LTE), there are chances that a few data points may be lost in case data is pushed every minute. Network check in NFH mode is done only at reboot. {% endhint %} **-- pending - OLED images/videos when NFH is running --** ### SD Card LYNX data logger supports external SD card as peripheral for local data storage. It is used as a temporary storage for Network Failure handler. It can also be used for local logging. Following are the steps to use SD card: 1. SD card has to be inserted in the LYNX SD card slot prior to booting up. 2. SD card check box has to be enabled under NFH settings. When SD card is enabled, LYNX ***mounts*** the SD card during setup. {% hint style="success" %} LYNX message after SD card was mounted successfully during setup {% endhint %}

#### -- OLED display for SD card pending pending -- LYNX supports SD card of up to 16GB. It is preferable to use 8GB SD cards. Few variants of 16GB SD cards (or higher capacity) are not mounted in LYNX. In this case, the following error is displayed during setup: **-- OLED display for SD card error pending--** ### NFH SD card Directory This is the directory within the SD card where temporary files are stored for NFH. The default directory for NFH is **`/nfhBkpDir`** . This directory is created by LYNX if it is not present in the SD card. Typically, it is not required to change this directory. If at all needed, it should be of exactly 9 characters and should be prefixed by /. For example **`/customDir`** Any other character length input will be ignored by LYNX. {% hint style="warning" %} For successful NFH operations, it is mandatory to have RTC, SD card and valid timestamp working. Otherwise, NFH will not work as desired. {% endhint %} ### Network Fallback By default, only one network (4G/LTE, Ethernet or Wi-Fi) is selected in network setting. With Network Fallback feature, LYNX offers fallback to second network at bootup time. At present, fallback from 4G/LTE to Ethernet is available. {% hint style="info" %} LYNX is not intended to work in multi-network failover modes. For these cases, it is suggested to use advanced router and cloud access is provided through Ethernet. {% endhint %} ### **YuReCon** YuDash supports YuReCon (YuDash Remote Configuration) for in-field deployed devices. Please refer to [YuRecon](#yurecon) documentation for further details and architecture. YuReCon is enabled within **Advance Feature Setting** as below:

# Cloud and Payload Settings Pleaser refer to [YuDash Device to Cloud API](/device-to-cloud-api/yudash-iiot-stack) for Cloud and Payload Settings. # Ethernet Settings LYNX has ethernet (RJ45) as optional hardware feature depending on part number. The ethernet port can be used for the following purposes: ### Network Connectivity through Ethernet Ethernet port is used to connect to cloud (or on-premise server). This is enabled by selecting Ethernet in Network Settings. In this case, there is no need to enable Ethernet under Feature Settings of LYNX. Ethernet supports dynamic IP (DHCP) and static IP option. By default, dynamic IP is assumed in which IP address is assigned by local LAN router. In this case, there is no further configuration in this section. This is the most common use-case for most of the applications. ### TCP/IP (or UDP) Communication with field instrument through Ethernet * Ethernet is used to communicate with PLC/HMI or other machines (using Modbus TCP/IP, SNMP, OPC-UA and other industrial protocols). * For this application, Ethernet/LAN has to be enabled under LYNX Feature settings. Subsequently, applicable TCP/IP based protocol has to enabled and configured. * It is feasible to use Ethernet port for both (1) Network connectivity and (2) Field instrument communication, assuming that instrument is connected to main network.

{% hint style="info" %} Enabling Ethernet/LAN under Feature Setting is not required when Ethernet is used only for network connectivity over default DHCP settings. {% endhint %} ## Updating Ethernet Settings in LYNX 1. Click on "Read Ethernet Settings" to load present settings. After clicking on "Update Ethernet Settings", the settings will updated. {% hint style="info" %} In case, there are not settings present, a popup "Ethernet Setting Not present" will be alerted. This reflects that default dynamic IP address of TCP/IP being used. {% endhint %}

2. For Static IP settings, select the "Static" radio button and fill the IP address details. Please fill either (a) ALL four entries or (B) ONLY IP address (applicable for peer-to-peer connection).

3. For dynamic IP, select In "Automatic/DHCP" radio button. With this selection, the custom IP address details are not used by LYNX. So, it is ok to leave them filled. # Modbus TCP/IP YuDash LYNX supports Modbus TCP/IP to read various PLC/HMIs through ethernet. In principle, following are the pre-requesites for using Modbus TCP/IP: 1. Valid Ethernet settings of YuDash LYNX for communication over TCP/IP. 2. LYNX is Modbus Client, who request the data. The given PLC is Modbus server, who will provide the data. LYNX can read multiple Modbus TCP/IP servers. 3. Following details of a given Modbus Server (PLC) are required for communication: * **IP address** of PLC. For example: ***192.168.1.100*** * **IP Port** on which Modbus server is running. For example: ***502*** (standard port). Or ***8888*** (any port being used by PLC) * **Modbus Server ID** as per protocol. For example: ***1*** (The Server ID of Modbus is similar to slave ID of Modbus RS-485) * **Modbus Registers and Data Types** The mapping of registers and selection procedure is similar to Modbus RS-485 There are different network topology possible for interfacing PLC/HMI with LYNX using Modbus TCP/IP. For example: #### A) Peer to Peer Direct Connection

#### B) Through Ethernet Switch

#### C) Through LAN Router with Static IP

#### D) Through LAN Router with Dynamic IP

All the scenarios of Modbus TCP/IP are covered in the video below. {% embed url="" %} # HTML Parser Settings There are many legacy instruments or systems which does not support standard industrial protocols like Modbus/Analog outputs. In many cases, there is a HTTP/web server running in the instrument, which can be accessed over Ethernet LAN. Historically, the instruments were connected to PC/laptop directly to PC (or in local LAN). The web pages were manually read by users and the current readings were manually recorded in registers or ERP. YuDash LYNX supports advanced HTML parsing for IoT enabling of legacy instruments. The feature is explained using a representative instrument with in-built web server. ### A) Sample Communication of Instrument with Laptop A representative instrument within inbuilt HTTP server is connected to laptop through Ethernet cable. The target HTML page (API) will open in the web browser. Please refer to instrument TCP/IP settings and documentation to reach to this point. Typically, the HTTP/web servers are running on IP port 80 and default page of index.html.

### B) Integration of YuDash LYNX with the instrument The laptop is now replaced with YuDash LYNX with similar topology. LYNX work as HTTP client (similar to web browser). Direct peer-to-peer connection is shown below. In practice, it can be connected to instrument (or a server/PC/SCADA) over various topologies, as explained in [Modbus TCP/IP](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-tcp-ip) section.

The HTML file of instrument will be processed by LYNX to extract applicable tags from HTML tables. The fetched data points will be treated similar to any Modbus/Analog values in rest of flow. ### C) Enabling HTML Parser Settings in LYNX 1\) Within [Feature Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings#features-settings), Ethernet/LAN and HTML parser is enabled. 2\) The [Ethernet Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/ethernet-settings) has to configured as per selected topology. In this example, Static IP settings are being used.

### D) HTML Parser Settings 3\) The Server settings of the instrument has to be filled within Read HTML Settings block. Click on **Read HTML Settings** to get present settings. Click on **Update HTML Settings** after updating settings of Server IP and API (as per below image). 4\) The HTML tags have to be configured as per HTML page of the instrument. The **Tag Name** is the tag within HTML table, the value of which has to captured. The value is assigned to **Variable Name**, which will be used in the LYNX data flow.

{% hint style="info" %} Besides default HTML parsing in this tutorial, YuDash LYNX supports advanced HTML parsing features. It includes capturing any HTML tags/tables based on the web page. It is done by configuring custom Prefix and Suffix tags for Keys and Values. Please contact us as for more help. {% endhint %} {% file src="/files/1Zs9D3PDrIAHL7xUFHrU" %} Sample HTML parsing block to be used in lynx.json configuration {% endfile %} # Digital Sensors Settings YuDash LYNX supports following digital sensors.

The configuration is presently done through LYNX JSON configuration interface. # ZENYX User Manual ## YuDash ZENYX Overview YuDash ZENYX is compact Industrial IoT Gateway, part of YuDash IoT Gateways and Data Loggers. It provides a flexible cloud connectivity to industrial and environmental instruments, PLC/HMIs and equipment. It supports a host of industrial protocols, including Modbus RS485, MODBUS TCP/IP, analog inputs. ZENYX acts as Modbus master and reads up to 96 parameters across 16 Modbus slaves. Four analog channels (0-20/4-20mA) are supported. ZENYX can connect to network (LAN or Cloud) through 4G/LTE, Ethernet and Wi Fi. ZENYX communicates with IoT platforms through MQTT, HTTP and FTP protocols. Effectively, any IoT platform can be connected using inbuilt JSON payload format library. It also has payload generator engine to support custom text and CSV payload. ZENYX can be easily configured in web-browser through laptop or mobile phone. On-device OLED display shows running status and simplifies deployment and debugging. Advanced features like input data scaling, two-way communication through Modbus-write, low power variants are available to support various use-cases. JSON based configuration backup and restoration aids deployment at scale. Product variants with subset of features are available for a cost-effective IoT gateway depending on application.

### Key Features * Easy to configure gateway over local Wi-Fi * Configurable through JSON file for mass deployments * On-device OLED for status and fault detection * Data Scaling feature to map inputs to required process parameters * Configurable looping cycles (10 second to 1 day). * Auto Reboot options * Low Power version with deep-sleep * Network failure handler: local storage and back-filling ### **Technical Specifications** * Input Power: 24V DC Standard (12-28V) * DIN Rail / Wall mounting * 50 x 110 x 65mm * ABS plastic enclosure with IP30 rating * On device OLED display * Weight: 210 grams approx. * SMA female connector for external 4G/LTE Antenna * Micro SIM card slot ### **Cloud Connectivity Options** * 4G/LTE * Ethernet * Wi-Fi ### **Supported Industrial Protocols:** * Modbus RS485 * Modbus TCP/IP * Analog Inputs ### **Cloud Protocols:** * MQTT * HTTPS (REST API) **Payload Formats** * JSON: ZENYX has multiple inbuilt JSON payload formats to support various IoT platforms. * TEXT: Inbuilt payload generator for custom text and CSV formats. ## ZENYX Product Variants ### YuDash ZENYX IoT Gateway Part Numbers

Part No	4G/LTE	Ethernet	RS485	Analog	RTC	Data Logging
ZENYX44	true	true	true	true	true	false
ZENYX46	false	true	true	true	true	true

* Wi-Fi network connectivity common across all IoT Gateways. * RTC is standard feature across all variants. ## User Manual Overview The ZENYX user manual covers the following sections: * ZENYX Terminals, connections and wiring * ZENYX configuration for various aspects. * In most of the cases, relevant sections of [LYNX documentation](/yudash-iot-devices/lynx-user-manual) is referenced. * Refer to [YuDash Devices Features & APIs](/dc/df) for protocol specific features. {% hint style="info" %} As the ZENYX/LYNX UI is continuously evolving, some of interfaces in your product may be slightly different from the ones in manual. {% endhint %} # Terminals and Wiring ## Introduction ## YuDash ZENYX Terminals Front View of ZENYX

Terminal view of ZENYX

## ZENYX Power Connection

ZENYX is powered by 24V External Supply (red and black wire in the image below). ## ZENYX Peripheral Inputs Besides wire terminals, ZENYX has various input connections, as represented below:

## ## 4G/LTE SIM card Slot

## Ethernet LAN connection

## ZENYX Terminal Wiring Examples ## Modbus RS485 Wiring Modbus (A and B) terminals of ZENYX are connected to yellow and green wires respectively. 12/24V DC +/- power terminals are connected to red and black wires respectively.

# ZENYX Configuration ZENYX is configured through Wi-Fi using a laptop, tablet or mobile phone. There is no need to install any software or LAN wiring. Following are 3 simple steps to initiate ZENYX configuration. **Step 1**: On ZENYX bootup, the device waits for 5 seconds for user to start configuration server. The ZENYX screen shows the following message (with countdown from 5 to 0):

During the countdown, short press the Config button (present on top left side) to start the configuration server.

{% hint style="info" %} Do not long press the Config Button. Just push and release! {% endhint %} **Step 2:** Once the button is pressed, the device will enter in AP (Access Point) mode, meaning a Wi-Fi network will be broadcasted. The Wi-Fi SSID name and password are displayed on the ZENYX screen. Connect the laptop to the given Wi-Fi.

Details of Wi-Fi created by ZENYX are displayed on the ZENYX screen and are as follows: 1. Wi-Fi SSID: ***yu10001031*** 2. Wi-Fi password: **12345678** 3. ZENYX IP address: ***192.168.4.1*** {% hint style="info" %} **Troubleshooting Guide to connect to ZENYX Wi-Fi** 1\) In some cases, Wi-Fi may be shown as "Open network". In this case, no need to enter Wi-Fi password. 2\) At times, the Wi-Fi setting on laptop may be showing "Connecting.." instead of "Connected to Wi-Fi" after ZENYX Wi-Fi is selected. No need worry. Please open the Configuration URL (192.168.4.1) on laptop. It should simply open. 3\) In case of further trouble, please "Forget" any previously stored Wi-Fi names linked to ZENYX. {% endhint %} **Step 3:** This is how ZENYX configuration page looks like on laptop.

{% hint style="info" %} While laptop is connected to local Wi-Fi of ZENYX, internet will not be accessible on the laptop. {% endhint %} ZENYX will keep the configuration server running for up to 5 minutes on inactivity. All ZENYX configuration will be done through this page as covered in subsequent sections. **Following video explains the complete procedure to start ZENYX Configuration page** {% embed url="" %} ### ### ZENYX Configuration Sections Following are the main sections in YuDash ZENYX Configuration page: 1. **ZENYX Device Information**: This is read-only section with ZENYX model, hardware and firmware information. 2. **Network Setting**: This section is used to configure network connectivity of ZENYX. Depending on model, ZENYX can connect to internet through (a) 4G/LTE (SIM card) (b) Wi-Fi or (c) Ethernet LAN. It can also work in offline mode (when it is used for local storage or display only). 3. **ZENYX Settings**: This is main section in which all features of ZENYX are configured. It includes (a) Data send frequency, (b) Feature enable/disable (given industrial protocol) and (c) Custom cloud selection. Detailed configuration of a given feature is done in subsequent sections. ### ZENYX Device Information **ZENYX Device Information** read-only section with ZENYX model with following information:

1. **Part No**: The device part number. 2. **Serial No**: Unique serial number of the device. 3. **Hardware Ver**: Hardware PCB version. 4. **Firmware Ver**: ZENYX firmware version. 5. **Default Device Settings**: By default, each ZENYX gateway is pre-configured with "YuDash Cloud". Effectively, given IoT gateway is mapped to a unique "device" on YuDash IoT platform. 6. **Get Mac Address** **Button**: This button fetches the MAC address of the ZENYX IoT gateway. This MAC address is used for both Wi-Fi and Ethernet. {% hint style="info" %} MAC address of ZENYX is required for use of IoT gateway in enterprise networks for security purpose. The MAC address is required for "White Listing" of the gateway. In some cases, MAC address and static IP of device is tightly coupled to gain access to the network. {% endhint %} # Network Settings **Network Settings** section deals with connection of ZENYX with the network. It is typically internet or local LAN in some cases. Depending on model, ZENYX supports the following options to connect to network. 1. **Wi-Fi**: ZENYX connects to a Wi-Fi network (router) to access the internet/local LAN. All models of ZENYX support connection to internet through Wi-Fi. 2. **Ethernet**: ZENYX connects to internet through Ethernet (RJ45 jack). * By default, it assumes DHCP connection (in which IP address is assigned by router). In this case, no further change in setting is needed. * ZENYX also supports static IP address configuration under advanced Ethernet settings. 3. **4G/LTE (Sim card)**: LYNX connects to internet through 4G/LTE SIM card. * Support of all 4G networks, independent of carriers. LYNX has been tested with all carriers in India. * Option to provide carrier APN. Though, this is not critical. * Support of external antenna for in-panel applications. 4. **None (Offline)**: ZENYX is not being connected to any network and is being used as display unit. This mode is also used for debugging purpose. Please refer to [LYNX Network Setting](/yudash-iot-devices/lynx-user-manual/network-settings) page for further configuration steps. ## # ZENYX Settings ZENYX settings are based on the LYNX IoT Gateway. Please refer to [LYNX settings](/yudash-iot-devices/lynx-user-manual/lynx-settings) for the configuration. #### **Loading LYNX Settings from JSON in local laptop/PC.** ## ZENYX Features ZENYX supports various integration with various industrial protocols and cloud platforms. Each feature is covered under a different section in configuration page. It is scrollable from left bar. In most of cases, each section (or its sub-section) has an open, read and update button. Finally, one needs to do an "Update and Preview" and write to ZENYX, as explained in applicable LYNX tutorial. For first time users, it is recommended to write to ZENYX, power cycle the device and verify that given changes were actually updated in device. Following are the list of sections in Configuration page. These are documented as part of LYNX manual or separate integration guides. #### [Modbus RS485 Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-rs485) #### [Analog Input Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/analog-inputs) #### [DataScale Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/data-scaling) #### [Advance Feature Settings](#advance-feature-settings) 1. RTC Settings 2. Network Failure Handler Settings 3. YuReCon Settings #### [Custom Cloud Server Settings](/device-to-cloud-api/cloud-protocols) #### [Payload Settings](/device-to-cloud-api/payload-formats) #### [Ethernet Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/ethernet-settings) #### [Modbus TCP Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-tcp-ip) #### HTML Parser Settings #### SNMP Settings #### Extension Settings 1. Modbus RS485 Channel#2 #### 4G Modem Diagnostics Each feature is accessible from The feature details are covered in subsequent sections * # Modbus RS485 Modbus/RS485 is a popular serial protocol to read various sensors. YuDash ZENYX is being used to read a variety of instruments, sensors and PLCs for various applications. LYNX provides easy to configure approach for reading field Modbus instruments. Following are the key information points required for a successful read of instrument through Modbus: 1. Baudrate 2. Data Bits, Parity and Stop Bit 3. Slave ID of instrument 4. Modbus register information to read: 1. Modbus register numbers and types) 2. Modbus register data types (Size: integer/float/real. Byte swapping information: LSB/MSB etc.) 5. Modbus register address. ## Modbus Register Mapping in YuDash ZENYX. Refer to [LYNX Modbus RS485](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-rs485) documentation for more details for Modbus settings. Various Modbus topologies are covered in [Modbus protocol](/device-to-cloud-api/industrial-protocols/modbus) documentation. ## Modbus/RS485 interfacing example YuDash ZENYX is connected with XY-MD02 temperature and humidity sensor through Modbus/RS485. Refer to [XY-MD02](/integration-guides/industrial-instruments/process-control/temp+humidity-xy-md02) integration guide for register mapping.

# Analog Inputs Few variants of ZENYX support direct analog read inputs. ZENYX supports 4 channels of 0-20mA read. The terminals A1 to A4 terminals are available for 4 channels of analog. In most of industrial applications, 4-20mA values are mapped to given process values. ZENYX has advanced data scaling features to handle process values of different applications. While user can perform scaling within Analog Inputs, we recommend using generic [**Data Scaling**](/yudash-iot-devices/lynx-user-manual/lynx-settings/data-scaling) section of ZENYX/LYNX for analog data interpolation. ## Analog Input Settings **Analog Inputs Settings** has 4 buttons for 4 channels, which can be enabled/disabled and configured independently. **Analog Inputs** feature has to be enabled (check box) in LYNX Feature Settings to process analog channels.

## Analog Input Configuration 1. A given analog channel (A1 to A4) has to be enabled by clicking the checkbox. 2. Output values ranges \[**minOutVal,** **maxOutVal]:** These are the output value ranges (minimum and maximum) of the analog module. These can be used for basic linear scaling of inputs. If set to \[0, 100], the analog output will be 0 to 100 for given input mA range (0-20). 3. Input current range \[**minmA, maxmA**]: This is the range of input milli Amperes to be read. For most of the applications, this should be 0 and 20. For instrument calibration, the maxmA may be set lower than 20 (say 19.8) to map to real-world process values. 4. **varName**: The variable name in which output value will be stored. 5. **varName2**: For analog inputs, this is optional additional variable name in which analog output will be stored. Keep it blank unless necessary. 6. **varFactor**: The output value will be multiplied by the varFactor. We will keep it 1.

### Analog Input Source Wiring There are 4 analog inputs (A1, A2, A3 and A4) terminals along with two GND terminals. Sample connection of 4 analog sources connected to ZENYX. This is a typical scenario of ZENYX connected to environmental sensors with multiple analog outputs.

# Data Scaling Please refer to [Data Scaling section of LYNX](/yudash-iot-devices/lynx-user-manual/lynx-settings/data-scaling). # Advance Feature Settings The **Advance Feature Settings** contains a group of features for fine tuning of ZENYX for specific use-cases. Please refer to [LYNX Advance Feature Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/advance-feature-settings). # Cloud and Payload Settings Pleaser refer to [YuDash Device to Cloud API](/device-to-cloud-api/yudash-iiot-stack) for Cloud and Payload Settings. # Ethernet Settings ZENYX has ethernet (RJ45) as optional hardware feature depending on part number. Please refer to [LYNX ethernet settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/ethernet-settings) for further details. # Modbus TCP/IP YuDash ZENYX supports Modbus TCP/IP to read various PLC/HMIs through ethernet. Please refer to [LYNX Modbus TCP/IP](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-tcp-ip) documentation. # FELYX ## YuDash FELYX **YuDash FELYX data logger.** ## YuDash FELYX PDF Catalog # ONYX ## YuDash ONYX **YuDash ONYX** is a versatile industrial data logger and controller with a high-resolution touchscreen, flexible sensor connectivity, and IoT-ready cloud integration. Powered by the YuDash LYNX platform, it supports both on-premise and remote applications — ideal for SCADA systems, IT networks, and battery or solar-powered field stations. ONYX is perfectly suited for environmental, emission, and water quality monitoring solutions. {% embed url="" %} ## YuDash ONYX PDF Catalog {% file src="/files/qHG5z9En3dFjjjyBMMH0" %} # Setu Wireless Bridge for Industrial Assets ## YuDash Setu

## YuDash Setu Use Cases ### 1) Peer to Peer Communication

# QUBIX ## YuDash QUBIX Overview YuDash QUBIX is a versatile instrument controller and display. It is primarily used for analog (4-20mA) instruments.

# YuDash Catalogs YuDash LYNX {% file src="/files/pWJlqemGrJlyKkyYSxB4" %} # Product Information ## YuDash NUREX AIoT Data logger YuDash **NUREX** is a next-generation **AI-enabled Edge Data Logger** designed for mission-critical industrial and environmental monitoring applications. Built for reliability, compliance, and long-term field deployment, NUREX bridges the gap between raw sensor data and actionable intelligence—directly at the edge.

Engineered for **emission monitoring, environmental compliance, and complex industrial use-cases**, NUREX processes, validates, and secures data locally before transmitting it to cloud or regulatory systems. This approach ensures higher data integrity, reduced latency, and continued operation even under intermittent network conditions. At its core, NUREX combines **edge AI capabilities**, **multi-protocol industrial connectivity**, and **secure data handling** into a single compact platform. It supports diverse field instruments and protocols while enabling advanced logic, calculations, and contextual decision-making at the device level—unlocking new use-cases beyond traditional data logging. NUREX is fully aligned with **CPCB OCEMS requirements**, making it suitable for regulated emission and pollution monitoring deployments across industries. With built-in support for secure APIs, encrypted communication, and scalable architecture, it is equally prepared for enterprise, government, and OEM deployments. Designed and built in India, NUREX reflects a strong focus on **robust engineering, long lifecycle support, and adaptability**—empowering industries to move from simple data collection to **intelligent edge-driven operations**. ## NUREX Product Variants ## YuDash NUREX44 Data Logger **1) Core Processor** * Quad‑core Arm® Cortex®‑A55 (Armv8 64bit @ 1.6 GHz) * AI GPU: Arm® Mali™‑G52‑2EE * 1GB LPDDR4 RAM (or higher) **2) Storage** * 16 GB / 8GB storage (Industrial SD card / eMMC) **3) Ethernet (as per part number)** * Direct RJ45 port OR * USB type-C (use with USB to Ethernet converter) **4) 4G/LTE Connectivity (as per part number)** **5) Modbus/RS485 (dual ports)** * Each port can be configured as Modbus RTU Master or slave. **6) Analog Inputs (4-20 mA)** * 4 channel Analog Inputs (4-20mA/0-20mA). * 16 bit high precision ADC **7) Digital Input for Tipping bucket rain gauge** ### NUREX44 Part Numbers

Part No	Short Part No.	Ethernet/USB	4G/LTE	RAM	Storage
NUREX44LA1016	NUREX44	RJ45	India (Asia)	1 GB	16 GB
NUREX44UA1016	NUREX44U	USB	India (Asia)	1 GB	16 GB

## User Manual Overview The NUREX user manual covers the following sections: * NUREX Terminals, connections and wiring * NUREX configuration for various aspects. {% hint style="info" %} As the NUREX UI is continuously evolving, some of interfaces in your product may be slightly different from the ones in manual. {% endhint %} # Terminals and Peripherals ## YuDash NUREX Terminals #### Front View of NUREX

#### Terminal view of NUREX

### NUREX Network Ports NUREX is available in two hardware variants, differentiated by their network interface: * **NUREX44** – Equipped with a dedicated **Ethernet (LAN) port** for wired network connectivity. * **NUREX44U** – Equipped with a **USB Type-C port** for network connectivity via USB.

### NUREX44 Network ports

### NUREX44 Top view (4G antenna and RJ45 jack)

### NUREX44U Network ports

### NUREX44U Top view (USB-C and 4G antenna)

### NUREX Right side view (4G SIM slot)

## NUREX Connection Examples ### NUREX Terminal Wiring

### NUREX SIM card {% embed url="" %} # NUREX User Manual NUREX is configured through ethernet port. {% hint style="info" %} MAC address of NUREX is required for use of data loggers in enterprise networks for security purpose. The MAC address is required for "White Listing" of the gateway. In some cases, MAC address and static IP of device is tightly coupled to gain access to the network. {% endhint %} # NUREX Configuration NUREX is configured primarily through Ethernet port

#### Following are the list of sections in Configuration page. These are documented as part of LYNX manual or separate integration guides. #### [Modbus RS485 Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-rs485) #### [Analog Input Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/analog-inputs) #### [DataScale Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/data-scaling) #### [Advance Feature Settings](#advance-feature-settings) 1. RTC Settings 2. Network Failure Handler Settings 3. YuReCon Settings #### [Custom Cloud Server Settings](/device-to-cloud-api/cloud-protocols) #### [Payload Settings](/device-to-cloud-api/payload-formats) #### [Ethernet Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/ethernet-settings) #### [Modbus TCP Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-tcp-ip) #### HTML Parser Settings #### SNMP Settings {% hint style="info" %} MAC address of NUREX is required for use of data logger in enterprise networks for security purpose. The MAC address is required for "White Listing" of the data logger. In some cases, MAC address and static IP of device is tightly coupled to gain access to the network. {% endhint %} # Ethernet Settings NUREX has ethernet (RJ45) as optional hardware feature depending on part number. Please refer to [LYNX ethernet settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/ethernet-settings) for further details. # Modbus RS485 Modbus/RS485 is a popular serial protocol to read various sensors. YuDash NUREX is being used to read a variety of instruments, sensors and PLCs for various applications. NUREX provides easy to configure approach for reading field Modbus instruments. Following are the key information points required for a successful read of instrument through Modbus: 1. Baudrate 2. Data Bits, Parity and Stop Bit 3. Slave ID of instrument 4. Modbus register information to read: 1. Modbus register numbers and types) 2. Modbus register data types (Size: integer/float/real. Byte swapping information: LSB/MSB etc.) 5. Modbus register address. ## Modbus Register Mapping in YuDash NUREX. Various Modbus topologies are covered in [Modbus protocol](/device-to-cloud-api/industrial-protocols/modbus) documentation. ## Modbus/RS485 interfacing example YuDash NUREX datalogger is connected with Selec EM2M energy meter on Modbus channel#1

## Modbus/RS485 interfacing example (2channels) YuDash NUREX datalogger is connected with Selec EM2M energy meter on Modbus channel#1 and XY-02 temperature and humidity sensor on Modbus Channel#2.

# Analog Inputs NUREX44 supports 4 channel of 0-20mA read. The terminals A1 to A4 terminals are available for 4 channels of analog. In most of industrial applications, 4-20mA values are mapped to given process values. NUREX has advanced data scaling features to handle process values of different applications. While user can perform scaling within Analog Inputs, we recommend using generic [**Data Scaling**](/yudash-iot-devices/lynx-user-manual/lynx-settings/data-scaling) section for analog data interpolation. ### Analog Input Source Wiring There are 4 analog inputs (A1, A2, A3 and A4) terminals along with two GND terminals.

# Data Scaling Please refer to [Data Scaling section of LYNX](/yudash-iot-devices/lynx-user-manual/lynx-settings/data-scaling). # Modbus TCP/IP YuDash NUREX supports Modbus TCP/IP to read various PLC/HMIs through ethernet. Please refer to [LYNX Modbus TCP/IP](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-tcp-ip) documentation. # HTML Parser YuDash NUREX supports Modbus TCP/IP to read various PLC/HMIs through ethernet. Please refer to [LYNX Modbus TCP/IP](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-tcp-ip) documentation. # Modbus Server YuDash NUREX supports Modbus TCP/IP to read various PLC/HMIs through ethernet. Please refer to [LYNX Modbus TCP/IP](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-tcp-ip) documentation. # Multi-API NUREX has ethernet (RJ45) as optional hardware feature depending on part number. Please refer to [LYNX ethernet settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/ethernet-settings) for further details. # Advance Features The **Advance Feature Settings** contains a group of features for fine tuning of NUREX for specific use-cases. Please refer to [LYNX Advance Feature Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/advance-feature-settings). # System Tools The **Advance Feature Settings** contains a group of features for fine tuning of NUREX for specific use-cases. Please refer to [LYNX Advance Feature Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/advance-feature-settings). # Data Logger The **Advance Feature Settings** contains a group of features for fine tuning of NUREX for specific use-cases. Please refer to [LYNX Advance Feature Settings](/yudash-iot-devices/lynx-user-manual/lynx-settings/advance-feature-settings). # Custom Cloud Pleaser refer to [YuDash Device to Cloud API](/device-to-cloud-api/yudash-iiot-stack) for Cloud and Payload Settings. # NUREX for CEMS NUREX is fully aligned with **CPCB OCEMS requirements**, making it suitable for regulated emission and pollution monitoring deployments across industries. With built-in support for secure APIs, encrypted communication, and scalable architecture, it is equally prepared for enterprise, government, and OEM deployments.

# CPCB YuDash NUREX supports real-time data push to the **Central Pollution Control Board (CPCB)** Online Continuous Emission/Effluent Monitoring System (OCEMS) portal at `cems.cpcb.gov.in`. This is the national regulatory requirement for industries under CPCB monitoring. NUREX implements the **CPCB 2025 API** with AES-256 encryption as mandated by CPCB guidelines. Data is pushed at configurable intervals (typically every 15 minutes) directly from the NUREX device to the CPCB server. Please refere to following link for CPCB OCEMS documentaton: *** ## Required CPCB credentials for Configuration Before configuring NUREX, you must have completed registration on the CPCB OCEMS portal and received the following credentials: ### 1) CPCB Tokens Following is a sample set of credentials received from CEMS CPCB authority after your industry is registered on the OCEMS portal. This email contains all the credentials needed to configure NUREX. Note down the following from this email: * **Industry Id** — your industry registration ID * **Device ID** — unique device identifier assigned by CPCB * **Station Id** — monitoring station identifier * **Token Id** — authentication token used for AES-256 encryption

*** ### 2) CPCB Industry Key The industry Key has to be downloaded from relevant **Industry Key Generation** section in the CEMS portal. Following is sample industry key download snippet: Log in to `cems.cpcb.gov.in` and navigate to **Industry Key Generation** from the left sidebar. The public key dialog will appear showing the RSA public key in PEM format. Click **Copy Key** to copy the full key text to your clipboard — you will paste this into NUREX in a later step. {% hint style="info" %} You need to click **Generate New Key** if no key exists. This step may lose all created devices. So, it is advisable to have the Industy Key generated before stations and devices are added. {% endhint %}

### 3) Approved Parameter List Only the approved parameters for a given station can be pushed to CPCB portal. The name of parameters and applicable units should be available for given station. *** ## NUREX Device Configuration for CPCB CPCB push is configured under **Multi-API mode** in the NUREX configuration page. This allows CPCB push to run alongside other API cloud destinations (MQTT, HTTP, FTP) simultaneously. #### Step 1 — Select Multi-API Cloud Mode Open the NUREX configuration page at `http:///api/config` and click **Multi-API Settings** from the left sidebar. The **Multi-Cloud API Settings** panel will appear. In the **Add API** row, enter a name for this API entry (e.g. `cpcb`) in the name field, then click the **Select API** dropdown.

*** #### Step 2 — Select CPCB from the API List The API type dropdown shows all supported PCB and cloud APIs. Select **Central CPCB (CEMS)** from the list. Other state PCB options (Tamil Nadu, Haryana, Punjab, Maharashtra, Madhya Pradesh, etc.) are also available for specific part number.

*** #### Step 3 — Add CPCB API in the API list With the name set to cpcb and Central CPCB (CEMS) selected, click the Add button. This creates the CPCB API entry as Seq#1 in your Multi-API configuration.

After adding, the **CPCB Configuration** panel appears. This panel has three fields to fill: * **Device ID** — from the CPCB approval email * **Station ID** — from the CPCB approval email * **Token ID** — from the CPCB approval email

#### Step 4 — Enter Token Settings Enter the **Device ID**, **Station ID**, and **Token ID** exactly as received in the CPCB approval email. Once filled, click **Manage Industry Key** to open the public key dialog where you will paste the key copied from the CPCB portal. Click **Populate & Verify JSON** after filling the fields to generate and validate the configuration.

{% hint style="info" %} The **Data Pause** option controls whether NUREX pauses data submission — leave it on **Never** for continuous monitoring. Use **On DI1** if you have a physical pause signal from your instrument system. {% endhint %} #### Step 5 — Enter Industry Key Once filled, click **Manage Industry Key** to open the public key dialog where you will paste the key copied from the CPCB portal. The **Industry Key** dialog shows the file location where the key will be saved on NUREX (`api directory/cpcb/public.pem`). Paste the full public key text copied from the CPCB portal — it must include the `-----BEGIN PUBLIC KEY-----` and `-----END PUBLIC KEY-----` lines.

NUREX confirms with a **"Public Key saved successfully!"** message. The key is now stored on the device at `api directory/cpcb/public.pem` and will be used automatically for AES-256 encryption of all data sent to the CPCB server. Click **OK** to close.

#### Step 6 — Device Registration with CPCB portal {% hint style="info" %} This step registers data logger with the CPCB ODAMS server and sets up a periodic heartbeat. It is required for full CPCB compliance but may not needed for basic data push to start. {% endhint %} {% hint style="info" %} **Disclaimer:** If the registration process stops or fails midway, it may not be possible to re-run it for the same Device ID. YuDash provides the registration wizard as a convenience mechanism and has no control over the CPCB registration software or server behavior. YuDash cannot provide support for registration failures — please contact CPCB directly in such cases. {% endhint %} After entering credentials and saving the Industry Key, click **Open Registration Wizard** under the **Device Registration** row. This opens the registration page in a new browser tab.

> **Use LAN/Ethernet only for this step.** The registration process downloads software components from the CPCB server. 4G/Mobile connections may cause timeouts and incomplete registration. Connect NUREX to a stable wired internet connection before proceeding. The **Device Registration: cpcb** page loads with two steps. The Device ID and Token ID are automatically pre-filled from your saved configuration. Download the CPCB registration executable (`main` file) from the CPCB portal. Select the **Linux ARM64** version — this is the correct binary for NUREX hardware. Click **Choose File**, select the downloaded `main` file, and click **Upload File**.

Verify that the Device ID and Token ID are correctly shown. Click **Start Registration** to begin the process.

The terminal window shows the registration progress in real time. NUREX connects to the CPCB ODAMS server, sends the Device ID and Token, receives a unique **Machine ID**, and sets up a cron job for periodic heartbeat.

{% hint style="info" %} A successful registration ends with: Response Status Code: success\ Device Register Successfully!\ Device Added Successfully {% endhint %} **Disclaimer:** If the registration process stops or fails midway, it may not be possible to re-run it for the same Device ID. YuDash provides the registration wizard as a convenience mechanism and has no control over the CPCB registration software or server behavior. YuDash cannot provide support for registration failures — please contact CPCB directly in such cases. ### Parameter Configuration & Data Flow This section explains the complete data flow from instrument to CPCB portal, using a 4-parameter effluent monitoring station as an example. In this example, four 4–20mA inputs are mapped to four CPCB approved parameters:

Channel	Variable Name	Parameter	Typical Unit
Ch 1	`bod`	Biological Oxygen Demand	mg/L
Ch 2	`cod`	Chemical Oxygen Demand	mg/L
Ch 3	`tss`	Total Suspended Solids	mg/L
Ch 4	`ph`	pH	pH

Each variable read by NUREX must be named using the **exact CPCB approved parameter name** for your station. The variable name in NUREX is what gets sent to the CPCB portal — so it must match the approved parameter list precisely. Input data can come from any source — Analog inputs, Modbus RS485, Modbus TCP/IP, or HTML Parser. In this example, four parameters are read from 4–20mA analog inputs. {% hint style="info" %} **The variable name must exactly match the CPCB approved parameter name — including lower/upper case.** For example, use `bod` not `BOD`, `ph` not `PH`. Only the approved parameters from NUREX master list are pushed to CPCB API, other parametersa are skipped. NUREX automatically assigns the correct unit for each recognised parameter — no manual unit entry is needed. {% endhint %} Open **Analog Input Settings → Open Analog Wizard → Channel Matrix**. Enable each channel, select the input topology (e.g. 0–20mA), and enter the **Variable name** using the exact CPCB approved parameter name for that channel.

Open **DataScale Settings** and configure the input-to-output scaling for each variable. This converts the raw 4–20mA signal from the instrument into the actual engineering value sent to CPCB. !\[Image 18 — Data Scale Settings showing scaling for bod, cod, tss, ph with Variable Name column highlighted] In this example: * `bod`, `cod` — 4–20mA input mapped to 0–300 mg/L output, cutoff –1 to 300 * `tss` — 4–20mA input mapped to 0–150 mg/L output, cutoff –1 to 150 * `ph` — 4–20mA input mapped to 0–14 pH output, cutoff –1 to 14

Enable the **Enable Scaling Flag** for each active variable. NUREX sends the scaled output value to CPCB — units are automatically applied based on the parameter name. {% hint style="info" %} If your approved parameter is not in the NUREX default list, or CPCB has specified a non-standard unit for your station, NUREX supports custom parameter addition and unit override. Contact [YuDash support](mailto:info@yudash.com) for assistance {% endhint %} ### Data Push Timing & Averaging

CPCB guidelines require data to be submitted at **15-minute intervals**, exactly at **xx:00, xx:15, xx:30, and xx:45** of each hour. Each submission must represent the **average of per-minute readings** over that 15-minute window (15 samples per push). NUREX handles this automatically: * Set **TimeSync Run (Minute)** to `1` so that NUREX reads the input parameter every 1 minute. * NUREX internally averages the 15 per-minute readings and pushes the result at each 15-minute boundary * The averaging window and push timing are managed by the NUREX CPCB API — no manual configuration is needed. There is option to over-rider the averaging mechanism. ### Security & Encryption All data transmitted from NUREX to the CPCB OCEMS portal is protected by the encryption and authentication framework mandated under the CPCB 2025 API guidelines: * **AES-256-CBC encryption** — every data payload is encrypted using the industry-specific RSA public key obtained from the CPCB portal before transmission * **Token-based authentication** — each request is authenticated using the unique Token ID issued by CPCB, ensuring only registered devices can submit data for a given station * **HTTPS transport** — all communication with `cems.cpcb.gov.in` is over TLS-secured HTTPS, preventing interception or tampering in transit * **Device binding** — the Machine ID assigned during device registration ties the NUREX unit to the specific CPCB device record, preventing unauthorized substitution The entire security layer — key management, payload encryption, token handling, and secure transmission — is handled automatically by NUREX firmware based on the credentials provided during configuration. No additional security configuration is required from the user. *** ## Troubleshooting *** ## YuDash CEMS and AKSH Platform # Device Configuration YuDash IoT devices can be configured through WiFi and Ethernet LAN (based on part number). The configuration steps are similar across YuDash IoT devices like LYNX and ZENYX.

Control flow for configuration of YuDash IoT devices

## WiFi based device configuration YuDash IoT device is configured through Wi-Fi using a laptop, tablet or mobile phone. In this case, there is no need to install any software or LAN wiring. Following are 3 simple steps to initiate configuration. **Step 1**: On device bootup, the device waits for 5 seconds for user to start configuration server. The device screen shows the following message (with countdown from 5 to 0):

**Step 2** During the countdown, short press the Config button of device to start the configuration page 1\) For LYNX, the Config button is connected with SW GND top right terminal:

2\) For ZENX, the Config button is on top left side. {% hint style="info" %} Do not long press the Config Button. Just push and release! {% endhint %} **Step 3:** Once the button is pressed, the device will enter in AP (Access Point) mode, meaning a Wi-Fi network will be broadcasted. The Wi-Fi SSID name and password are displayed on the device screen. Connect the laptop to the given Wi-Fi.

Details of Wi-Fi created by LYNX are displayed on the LYNX screen and are as follows: 1. Wi-Fi SSID: ***yu10000492*** 2. Wi-Fi password: **12345678** 3. Device IP address: ***192.168.4.1*** {% hint style="info" %} **Troubleshooting Guide to connect to Device Wi-Fi** 1\) In some cases, Wi-Fi may be shown as "Open network". In this case, no need to enter Wi-Fi password. 2\) At times, the Wi-Fi setting on laptop may be showing "Connecting.." instead of "Connected to Wi-Fi" after LYNX Wi-Fi is selected. No need worry. Please open the Configuration URL (192.168.4.1) on laptop. It should simply open. 3\) In case of further trouble, please "Forget" any previously stored Wi-Fi names linked to YuDash IoT device. {% endhint %} **Step 3:** This is how Device configuration page looks like on laptop.

{% hint style="info" %} While laptop is connected to local Wi-Fi of LYNX, internet will not be accessible on the laptop. {% endhint %} The device will keep the configuration server running for up to 5 minutes on inactivity. All the device configuration will be done through this page as covered in subsequent sections. **Following video explains the complete procedure to start LYNX Configuration page** {% embed url="" %} ## Ethernet LAN based device configuration YuDash IoT devices which have ethernet port can also be configured through Ethernet LAN during bootup. **Step 1**: On device bootup, the device waits for 5 seconds for user to start configuration server. **Step 2:** During the countdown, short press the Config button of device to start the configuration page 1\) For LYNX, the Config button is connected with SW GND top right terminal: 2\) For ZENX, the Config button is on top left side. **Step 3:** Once the button is pressed, the device will enter in AP (Access Point) mode, meaning a Wi-Fi network will be broadcasted. For devices with ethernet LAN, the device also starts LAN server on fixed static IP of **192.168.2.1. In this case, the display screen shows both IP address for 1 second each.**

YuDash IoT devices displaying WiFi and ethernet LAN settings in tandem

**Step 4:** Connect the laptop to YuDash IoT device through ethernet LAN cable directly. Configure laptop network settings to have static IP address for ethernet. With reference to following illustration, the IP address of YuDash IoT device is **192.168.2.1** during configuration. So, laptop has to be assigned IP address in series of **192.16.2.X**. In the example, IP address of **192.168.2.209** is assigned to laptop.

**Step 5**: Once the laptop is connected to the YuDash IoT device, open the page 192.168.2.1 in browser, which will open like following:

The user need to enter login name and password to access the device. Default login is admin and default password is **password**. Press the button "Login to Device" after entering login and password:

On successful login, a pop-up will show "Login success". In case of password error, error message will pop up.

After successful login, the sections of **Device Configuration** and **Realtime Telemetry** are enabled in the page. Click on **Open Configuration Page**, which will open the configuration page in separate tab.

When the button Open Configuration page is clicked, a confirmation pop-up will appear as below:

The configuration opens in separate tab, which can now be used for device configuration. This page is identical to WiFi based configuration.

**Following video explains the steps to start LYNX Configuration page through LAN** {% embed url="" %} # Configuration JSON download/upload All YuDash IoT devices are configured using a single JSON configuration file (typically called **`lynx.json).`**This file defines everything about the device — from sensor inputs, logic formulas, and network settings, to output behavior and communication protocols. Think of `lynx.json` as the **"PLC program"** for your YuDash device. You can either: * Edit settings using the **built-in web UI**, or * Modify the `lynx.json` file directly for advanced customization. > ✅ Once your configuration is stable and tested, it is **good practice to download the current `lynx.json` file**. This serves as a backup and can be reused for future deployments. ### YuDash Configuration JSON file download {% embed url="" %} ### YuDash Configuration JSON file upload {% embed url="" %} # Device Features This section covers common features and APIs of YuDash IoT devices. Please refer to availability of given feature based on part number. # Network YuDash IoT devices support various options to connect to network (cloud or LAN)

Network Connectivity	Typical Use-Cases.
4G/LTE	Standalone IoT connectivity through SIM card. This provides a reliable connectivity without any external dependies.
Ethernet	a) IoT gateway connected to Internet enabled LAN. b) IoT coupled with 4G/LTE router. c) IoT gateway connected to LAN with local/on-prem server.
WiFi	a) IoT gateway connected to Internet enabled LAN through WiFi. b) IoT coupled with 4G/LTE Wifi router. c) IoT gateway connected to LAN with local/on-prem server. It is important to have a strong Wi-Fi for a reliable connection
LoRaWan	YuDash IoT devices do not support LoRaWan at present.

## **Network Settings** **LYNX Network Settings** section deals with connection of LYNX with the network. It is typically internet or local LAN in some cases. Depending on model, LYNX supports the following options to connect to network: 1. **Wi-Fi**: LYNX connects to a Wi-Fi network (router) to access the internet/local LAN. All models of LYNX support connection to internet through Wi-Fi. 2. **Ethernet**: LYNX connects to internet through Ethernet (RJ45 jack). * By default, it assumes DHCP connection (in which IP address is assigned by router). In this case, no further change in setting is needed. * LYNX also supports static IP address configuration under advanced Ethernet settings. 3. **4G/LTE (Sim card)**: LYNX connects to internet through 4G/LTE SIM card. * Support of all 4G networks, independent of carriers. LYNX has been tested with all carriers in India. * Option to provide carrier APN. Though, this is not critical. * Support of external antenna for in-panel applications. 4. **None (Offline)**: LYNX is not being connected to any network and is being used as display unit. This mode is also used for debugging purpose.

## Read and Write Network Settings 1. **Click on "Read Network Settings"** button. The network settings will be populated in configuration page from LYNX. It may take 1-2 seconds for this process.

2. Various network Settings are populated in the configuration page from LYNX. Apply required changes in given section.

## Selection of Network Settings in LYNX **Network Selection** radio button is used to select a given type of network. Details of each network type is covered in following sections.

2. In the above settings, the SSID#1 has been changed from yudashdemo to my\_test\_1 and password has been updated. Similarly, WIFI SSID#2 has been changed to mytest2.

{% embed url="" %} ## Updating Ethernet Settings in LYNX Ethernet port can be used to connect to cloud (or on-premise server). This is enabled by selecting Ethernet in Network Settings as below.

### **LYNX display during Ethernet Setup**

# Modbus/RS485 Modbus instrument integration of YuDash IoT devices Modbus/RS485 is a popular serial protocol to read various sensors. YuDash IoT gateways and dataloggers are being used to read a variety of instruments, sensors and PLCs for various applications. LYNX provides easy to configure approach for reading field Modbus instruments. Following are the key information points required for a successful read of instrument through Modbus: 1. Baudrate 2. Data Bits, Parity and Stop Bit 3. Slave ID of instrument 4. Modbus register information to read: 1. Modbus register numbers and types) 2. Modbus register data types (Size: integer/float/real. Byte swapping information: LSB/MSB etc.) 5. Modbus register address. ## Modbus Register Mapping in YuDash IoT devices. Following four inputs have to be provided for processing of each Modbus register in YuDash IoT gateways. We use YuDash LYNX in below documentation: 1\) **Variable Name:** YuDash LYNX reads a given Modbus register and stores it in a variable. This is the user defined string, which will be sent to IoT platform/server along with the process values. For sending to YuDash cloud, the variable names should be all small letters without any blank spaces. Sample variable name: **volt1 temperature\_celcius amp\_01 amp\_02 machine\_status\_flag** 2\) **Register Number:** The register types/function codes of Modbus are defined by register numbers. User has to specify complete **#Register No.** in Modbus register section. Following is the available range of registers: | Function Code | Registers | Range | | ------------- | --------------------- | ----------- | | **1** | **COIL STATUS** | 0-9990 | | **2** | **INPUT STATUS** | 10000-19999 | | **4** | **INPUT REGISTERS** | 30000-39999 | | **3** | **HOLDING REGISTERS** | 40000-49999 | {% hint style="info" %} Important Note: LYNX uses base-0 register addressing (starting with 40000). OEM instrument manual uses both base-0 or base-1 registers, so that they have to checked accordingly. The MODSCAN uses base 1 register addressing (starting with 40001). So, after MODSCAN registers are identified, you have to enter register as one less than the MODSCAN register. {% endhint %} 3\) **Type**: The data type of Modbus registers are specified in data **Type** code in MODUS register settings. Following are the register type codes:

Type	Description	No. of Registers read	Byte Sequence
1	SIGNED INTEGER	1
2 or 20	Floating Point (LSB first)	2	CDAB
21	Floating Point (MSB first)	2	ABCD
22	32bit Integer (LSB first)	2	CDAB
23	32bit Integer (MSB first)	2	ABCD
24	32bit Unsigned Integer (LSB first)	2	CDAB
25	32bit Unsigned Integer (MSB first)	2	ABCD
11	Bit pattern Extraction	1

Type	Sequence	Type	Sequence	Data Type
4 or 40	RSPQ	401	SRQP	Float 64
41	PQRS	411	QPSR	Float 64
42	RSPQ	421	SRQP	Int 64
43	PQRS	431	QPSR	Int 64

2. Energy Meter MODUBUS settings checked in MODSCAN software.

3. Voltage and Frequency values test-read in MODSCAN software and co-related with datasheet values.

4. Corresponding settings updated in YuDash LYNX Modbus/RS485 section.

Following video explains the steps for updating Modbus/RS485 settings in LYNX. Similar process is applicable for other YuDash IoT devices: {% embed url="" %} # Modbus Poll Tutorial For a new instrument integration with IoT, it is advisable to first read a given set of registers using PC based software to validate Modbus settings of the instrument. Following are two popular software tools used in the industry: 1\) Modscan [download link](https://www.win-tech.com/) 2\) Modbus Poll [download link](https://www.modbustools.com/download.html) {% hint style="info" %} The integration of instrument with PC based software is not in YuDash support scope. The details of software are shared for reference only and ease of integration. {% endhint %} In this tutorial, steps for reading the Modbus instrument using YuDash IoT device with help of Modbus poll is explained (with focus on data type). Following are steps involved ## 1) Modbus read through Modbus Poll 1a) Interface the given Instrument using Modbus poll software. 1b) A sample modbus register value has been read in Modbus poll and a non-zero value is validated successfully.

{% hint style="info" %} Details and support for above step (1)is outside the scope of YuDash support. As per customer requirement, YuDash provided online training and RS-485 to USB kit on chargeable basis. {% endhint %} ## 2) Mapping of Modbus-Poll Settings to YuDash Modbus

RS485/Modbus instrument is connected to YuDash IoT device

### 2a) Baudrate and parity settings

### 2b) SlaveID, register and display type mapping

## 3) Mapping of Display data types to YuDash Modbus Types There are various data types (16, 32 and 64 bit) applicable in Modbus. It is important to have correct data type selected while reading the instrument/PLC from YuDash IoT devices. The data types are explained in [Modbus Integration guide. ](https://docs.yudash.com/dc/df/modbus/pages/VogxISTVQJKQuRFsVKvT#h.jt0n9eorg4hg_l) After successful read of register in step 1b, corresponding code in "Type" has to be filled in YuDash Modbus settings as per below mapping:

### Data Type for 16 bit integers

### Data Type for 32 bit signed integer

### Data type for 32 bi unsigned integer

### Data type for 32 bit Float

### Data type for 64 bit data types YuDash supports few 64 bit register data types which are converted to 32 bit floating point numbers. ## Byte Alignment Reference

## 4) Technical Notes ### 4a) Data exchange between YuDash IoT and RS485 instrument

# String read in RS485/RS232 YuDash devices use the built-in **Modbus RS485/RS232 interface** to receive ASCII/text data from serial instruments such as weather sensors, analyzers, or weighing systems. The interface is defined as custom Modbus registers, for a flexible **raw text inputs** parsing. The input string is defined with modbus register value of 60000 range. mbReg: 60ABC: ABC represent maximum bytes to be read from the input stream. varType: defines the format and handline of input read. The input can be treated as String (ASCII) or HEX data: 1. String: Input treated as ASCII/text data. This is applicable for varType range 50-54. 2. Hex: The input is treated as HEX data. A two character output in capital letters (followed by a space) is written for every input hex byte. This is applicable for varType range 55-59.

varType	Input Type	Input read behavior
50	String	Terminate input read at new line (\n, or \r). Flush balance input buffer after read.
51	String	Do not terminal at newline. Read all input bytes based on mbReg.
52	String	Terminate read at new line (\n, or \r). Do not flush buffer after serial read.
55	Hex	Terminate input read at new line (\n, or \r). Flush balance input buffer after read.
56	Hex	Do not terminal at newline. Read all input bytes based on mbReg.
57	Hex	Terminate read at new line (\n, or \r). Do not flush buffer after serial read.

#### Sample Modbus Slave settings for String input * **slaveID and mbRegCnt:** These value remain 1 as default. * **varName**: The output variable name (**voltage\_string**) in which output string will be stored for further processing. * mbReg: 60050. A register number >6000 represent string input read. 50 represents maximum 50 bytes to be read from the input. This can be set based on estimated text input line from the instrument. * varType: 50. 50 means we treat input as string (ASCII), terminate reading at a newline and flush the baalnce input buffer. This will be the typical setting for most of the use-cases. ```json // modbus settings for RS485 string read "modBusSlaves": [ { "slaveID": "1", "mbRegCnt": 1, "mbArray": [ { "varName": "voltage_string", "mbReg": "60050", "varType": "50", "varFactor": "1" } ] } ], ``` # Modbus TCP/IP YuDash LYNX supports Modbus TCP/IP to read various PLC/HMIs through ethernet. In principle, following are the pre-requesites for using Modbus TCP/IP: 1. Valid Ethernet settings of YuDash LYNX for communication over TCP/IP. 2. LYNX is Modbus Client, who request the data. The given PLC is Modbus server, who will provide the data. LYNX can read multiple Modbus TCP/IP servers. 3. Following details of a given Modbus Server (PLC) are required for communication: * **IP address** of PLC. For example: ***192.168.1.100*** * **IP Port** on which Modbus server is running. For example: ***502*** (standard port). Or ***8888*** (any port being used by PLC) * **Modbus Server ID** as per protocol. For example: ***1*** (The Server ID of Modbus is similar to slave ID of Modbus RS-485) * **Modbus Registers and Data Types** The mapping of registers and selection procedure is similar to Modbus RS-485 There are different network topology possible for interfacing PLC/HMI with LYNX using Modbus TCP/IP. For example: #### A) Peer to Peer Direct Connection

#### B) Through Ethernet Switch

#### C) Through LAN Router with Static IP

#### D) Through LAN Router with Dynamic IP

All the scenarios of Modbus TCP/IP are covered in the video below. {% embed url="" %} # Modbus Server Typically, YuDash IoT devices act as Modbus master (client) reading data from the instruments or PLCs. The data is sent to some cloud server through MQTT or REST API. There are many applications in which aggregated data is required on SCADA systems. For these applications, YuDash IoT devices act as per Modbus Server (Slave) on a given RS485 port or Ethernet (Modbus TCP/IP). Effectively any inputs read by YuDash (4-20mA analog inputs, RS485 or even MQTT subscribe) can be provided on Modbus server on configured port. The YuDash IoT devices can be configured as dedicated Modbus server or they can be configured in parallel to regular cloud data push. Modbus Server feature is explained in following tutorials: ## [YuDash ZENYX for Analog to Modbus RS/485 Server (Slave)](/dc/df/ms/anambus)

YuDash LYNX as Analog to Modbus TCP/IP Server YuDash IoT devices support acting as Modbus Server (RS485 or Modbus TCP/IP) # Analog to Modbus/RS485 Server (Slave) In this tutorial, YuDash ZENYX will be used to read 4 channel analog inputs (4-20mA) and act as Modbus/RS485 slave (server). {% hint style="info" %} Ready-to-use json configuration files are available for ZENYX and LYNX in the end of the tutoral. They can simply be loaded into the device for quick start. {% endhint %} ## 1) Connection Diagram

1. Test setup of 4 channel 4-20mA analog generator is connected (red line) to analog inputs of ZENYX. The value of 5, 10, 15 and 20 mA are being generated in the test setup. 2. The Modbus/RS485 is connected to RS485-USB converter (yellow and green) for modbus read on the laptop. ZENYX Modbus/RS85 is configured as modbus slave (server). 3. The Modbus Poll software is acting as modbus master in the laptop. It is reading ZENYX Modbus/RS485 and receiving 4 analog values on given modbus registers. {% hint style="info" %} Modbus Poll [download link](https://www.modbustools.com/download.html) {% endhint %} ## 2) General Settings in ZENYX settings

* **Loop Delay** is set to 0. As we act as server, we want to read input data continuously without any delay. * **Analog Inputs** is enabled to read 4-20mA input. * The Cloud/Network set to to "**Offline**". In this usage, we are not sending data to any server. {% hint style="info" %} Notes in general settings: 1\) Modbus/RS485 is NOT enabled here (which makes YuDash as Modbus master). We will be enabling Modbus/RS485 server in the next step 2\) The datascale feature of YuDash can be used to scale the analog input to required process values. This is not covered in this tutorial for simplicity. {% endhint %} ## 3) Analog Input Settings in ZENYX

* **Analog Input Settings:** The four analog inputs are enabled. We read 0-20mA inputs. * The four variables are read as **analog1**, **analog2**, **analog3** and **analog4**. These variables will be mapped to Modbus/RS485 server register in next section. ## 4) Modbus Server Settings

* **Modbus Server Type:** This is selected as RS485. This pertains to RS485 acting as Modbus Server (Slave). *In case of LYNX, this maps to first RS485 channel acting as server.* * **Modbus RS485 Server Settings:** * Modbus Server Id: Enter the Slave ID as per choice. (selected as 1 at present) * BaudRate: Required baud rate. Selected as 9600. * Data Parity: Required data parity. Selected as 8N1. * **Modbus Server Register Settings block** * You need to click "Open Modbus Server Settings" to open the details. * Click on "Read Modbus Server Settings" to check existing mappings. * Click on "Update Modbus Server Settings" after any changes. * **Modbus Server Register Settings** * Input variables "analog1" is mapped to 40000 register as floating point output. * The "Var Type" is set to 2 (floating point data type). This is the only supported data type at present. So, 2 modbus registers are used for one variable. * The "Enable Modbus Register" checkbox enables the value. This entry is ignored/delete if the check box is not present. * In the tutorial, the four analog inputs variables (analog1, analog2, analog3 and analog4) are mapped to registers 40000 40002 40004 and 40006 ## 5) Tutorial Json configuration file Above 4 steps complete the configuration in the ZENYX. These settings are readily available in the following json file. We recommend loading below json file to run through the tutorial. {% file src="/files/PzcfHV4L3cJMRaLTnGJT" %} ## 6) Advance Feature Settings (optional) These settings pertain to using TimeSync mode within "Advane Feature Settings". In case RTC and timeSync is enabled in the advance settings, loopDelay=0 will be ignored. In this case TimeSync Server Mode sould be enabled for fast response. *These settings are for specific advance use-cases and not required for the tutorial. We recommend loading ready-made json configuration files as starting point.*

## 6) Modbus poll read Reboot ZENYX after completing all settings. The input analog values should be available on modbus-poll on the laptop. Following are typical settings to match the Modbus server 1\) The Connection Setup is matched to 9600, 8N1

2\) The Slave ID is 1 and function is 0x3 (Read Holding Registers)

3\) The Display data type is "32 bit Float" with Little-endian byte swap

### **YuDash Modbus Server specifications** 1. The output registers are mapped in holding registers (starting from 40000). 2. The data type is fixed floating type (Var Type = 2). 3. The entries in the register map should be in increasing order only. 4. Maximum of 16 variables (32 registers) can be mapped to modbus register map. 5. The data scaling on input variables can be applied to receive process data on the modbus registers. ## 7) YuDash ZENYX as Analog to Modbus TCP/IP Server Similar to above tutorial, YuDash ZENYX can be configured as Modbus TCP/IP Server. Following is typical wire connection:

#### #### 7.1) Ethernet LAN is enabled to use LAN port for Modbus TCP/IP server

#### 7.2) Ethernet of YuDash ZENYX is configured as static IP

The IP address is assigned as static. Sample IP address of 192.168.2.73 is assigned. This IP address will be readby Modbus poll software. #### 7.3) Modbus Server Settings. * In Modbus Server Type Settings, "TCP/IP" is selected * The Modbus TCP/IP port of 502 is assigned. The IP address was assigned in 7.2 earlier. * The block of "Modbus RS485 Server Settings" is ignored. * Modbus Server ID remains 1 for Modbus TCP/IP. * Only server ID of 1 is supported in Modbus TCP/IP. The uniqueness is managed by port number.

## 8) Analog to Modbus TCP/IP Server Json file {% file src="/files/B5sgQma8EDBNwGBwtqJp" %} # Analog to Modbus/TCP-IP Server In this tutorial, YuDash LYNX will be used to read 8 channel analog inputs (4-20mA) and act as Modbus TCP-IP server {% hint style="info" %} Ready-to-use json configuration files are available for ZENYX and LYNX in the end of the tutoral. They can simply be loaded into the device for quick start. {% endhint %} ## 1) Connection Diagram

1. Test setup of 4 channel 4-20mA analog generator is connected (red line) to analog inputs of LYNX. The value of 5, 10, 15 and 20 mA are being generated in the test setup. LYNX will read 8 analog channels. So, balance 4 channels will have zero values. 2. The LAN cable is connected from ethernet port of LYNX to laptop. Modbus/TCP-IP server is configured on the ethernet LAN port. 3. The Modbus Poll software is acting as modbus TCP-IP client on the laptop. It is reading LYNX Modbus/TCP-IP and receiving 8 analog values on given modbus registers. {% hint style="info" %} Modbus Poll [download link](https://www.modbustools.com/download.html) {% endhint %} ## 2) General Settings in LYNXsettings

* **Loop Delay** is set to 0. As we act as server, we want to read input data continuously without any delay. * **Analog Inputs** is enabled to read 4-20mA input. * The Cloud/Network set to to "**Offline**". In this usage, we are not sending data to any server. * Ethernet/LAN is enabled {% hint style="info" %} Notes in general settings: 1\) Modbus/RS485 is NOT enabled here (which makes YuDash as Modbus master). We will be enabling Modbus/RS485 server in the next step 2\) The datascale feature of YuDash can be used to scale the analog input to required process values. This is not covered in this tutorial for simplicity. {% endhint %} ## 3) Analog Input Settings in LYNX

* **Analog Input Settings:** All 8 analog inputs are enabled. We read 0-20mA inputs. * The eight variables read are **analog1 to analog8** respectively. These variables will be mapped to Modbus/ TCP-IP server register in next section. ## 4) Ethernet LAN Settings

* Ethernet Settings are used to assign a static IP address to the LYNX * Static IP of 192.168.2.73 is assigned in this tutorial. This can be changed as per network topology. * This IP address will be used to read LYNX Modbus TCP-IP server in the Mobus poll. ## 5) Modbus Server Settings

* **Modbus Server Type:** This is selected as TCP/IP. This pertains to TCP/IP (LAN port) acting as Modbus Server. * **Modbus TCP-IP Server Settings:** * Modbus TCP/IP port: The TCP/IP port used to run the server. It is set to 502 in the example. * The section of "Modbus RS485 Server Settings" is not applicable. * Only Server Id of 1 is applicable for Modbus TCP-IP. * **Modbus Server Register Settings block** * You need to click "Open Modbus Server Settings" to open the details. * Click on "Read Modbus Server Settings" to check existing mappings. * Click on "Update Modbus Server Settings" after any changes. * **Modbus Server Register Settings** * Input variables "analog1" is mapped to 40000 register as floating point output. * The "Var Type" is set to 2 (floating point data type). This is the only supported data type at present. So, 2 modbus registers are used for one variable. * The "Enable Modbus Register" checkbox enables the value. This entry is ignored/delete if the check box is not present. * In the tutorial, the eight analog inputs variables (analog1 to analog8) are mapped to registers 40000 40002 40004, upto 40014. ## 6) Tutorial Json configuration file Above 5 steps complete the configuration in the LYNX. These settings are readily available in the following json file. We recommend loading below json file to run through the tutorial. {% file src="/files/LE6S6OMDJUOZLIgRCwbJ" %} In case RTC and timeSync is enabled in the advance settings, loopDelay=0 will be ignored. In this case TimeSync Server Mode sould be enabled for fast response. *These settings are for specific advance use-cases and not required for the tutorial. We recommend loading ready-made json configuration files as starting point.* ## 7) Modbus poll read Reboot LYNX after completing all settings. The input analog values should be available on modbus-poll on the laptop. Following are typical settings to match the Modbus server 1\) The Connection Setup is selected as Modbus TCP/IP and IP address of 192.168.2.73 is selected. Server port of 502 is selected.

2\) The "Display" is selected as 32-bit Float with Little-endian byte swap

3\) All 8 variables (16 registers) are visible in Modbus poll. First 4 registers have analog values from the test setup. Rest 4 analog inputs have zero values as they are not connected.

### **YuDash Modbus Server specifications** 1. The output registers are mapped in holding registers (starting from 40000). 2. The data type is fixed floating type (Var Type = 2). 3. The entries in the register map should be in increasing order only. 4. Maximum of 16 variables (32 registers) can be mapped to modbus register map. 5. The data scaling on input variables can be applied to receive process data on the modbus registers. ## 8) YuDash ZENYX as Analog to Modbus TCP/IP Server Similar to above tutorial, YuDash LYNX can be configured as Modbus TCP/IP Server. Following is typical wire connection:

#### #### 7.1) Ethernet LAN is enabled to use LAN port for Modbus TCP/IP server

#### 7.2) Ethernet of YuDash ZENYX is configured as static IP

## 8) Analog to Modbus TCP/IP Server Json file # Ethernet YuDash IoT devices have ethernet (RJ45) as optional hardware feature depending on part number. The ethernet port can be used for the following purposes: ### Network Connectivity through Ethernet Ethernet port is used to connect to cloud (or on-premise server). This is enabled by selecting Ethernet in Network Settings. In this case, there is no need to enable Ethernet under Feature Settings of LYNX. Ethernet supports dynamic IP (DHCP) and static IP option. By default, dynamic IP is assumed in which IP address is assigned by local LAN router. In this case, there is no further configuration in this section. This is the most common use-case for most of the applications. ### TCP/IP (or UDP) Communication with field instrument through Ethernet * Ethernet is used to communicate with PLC/HMI or other machines (using Modbus TCP/IP, SNMP, OPC-UA and other industrial protocols). * For this application, Ethernet/LAN has to be enabled under LYNX Feature settings. Subsequently, applicable TCP/IP based protocol has to enabled and configured. * It is feasible to use Ethernet port for both (1) Network connectivity and (2) Field instrument communication, assuming that instrument is connected to main network.

2. For Static IP settings, select the "Static" radio button and fill the IP address details. Please fill either (a) ALL four entries or (B) ONLY IP address (applicable for peer-to-peer connection).

3. For dynamic IP, select In "Automatic/DHCP" radio button. With this selection, the custom IP address details are not used by LYNX. So, it is ok to leave them filled. # Data Logging YuDash data loggers support periodic data logging to an onboard microSD card. This feature is essential for applications requiring offline storage, regulatory audit trails. The files in the microSD card can be downloaded in laptop or it cane be accessed through YuDash interface. ## Data Logger Configuration ### 1. Enabling Data Logging To enable the SD card logging feature: 1. Navigate to the **LYNX Settings** section from the side menu. 2. In the **Feature Settings** block, check the box labeled **Data Logging**. 3. Click **Write LYNX Config** to save the changes.

4. SD Card logging requires both the **SD Card** and **RTC (Real-Time Clock)** features to be enabled in the configuration. If either is disabled, the logger will not function. Make sure both checkboxes are selected before setting up the data logger.

### 2. Data Logging Section * **Navigate** to the **Data Logger Settings** tab from the sidebar. * Click **Read Data Logger Settings** to load the current configuration from the device. * Modify the necessary fields such as: * Logging interval * File cycle and naming * Encoder pattern or custom header * After making changes, click **Update Data Logger Settings** to save the configuration to the device. * There is an option to tick **Use Default Settings**. When this is enabled, the data logger uses its internal default configuration and other blocks can be blank. As soon as you provide any **custom entry** — like a header text or an encoder format — the corresponding default is overridden. Only fields left blank will fall back to default behavior.

### 3. File directory and name In this section, you configure where and how the data logger files will be stored:

1. **Logger Directory**: Specifies the folder path on the SD card where log files will be created. Points to note: 1. The path must begin with a forward slash `/` (root directory). 2. Use `/` as the folder separator (like in Unix/Linux), **not** the Windows-style backslash `\`. 3. **Do not** add a trailing slash at the end of the path.\ ✅ `/logger_dir` ❌ `/logger_dir/` or `\logger_dir\` 4. The directory will be **automatically created** if it does not already exist on the SD card. 2. **File Name** YuDash provides flexible file naming by allowing a customizable **prefix**, dynamic **timestamp insertion** (based on selected cycle), and optional **suffix**.\ This makes it easy to: * Align with existing file naming conventions in your systems * Simplify automated file parsing or importing on downstream software * Organize logs by project, device, or department The file name is constructed using a **prefix**, the **cycle-based timestamp**, and a **suffix**. The suffix is typically `.csv`, `.txt`, or any other extension as per your application's needs. **File Name**: Define a custom file name using a **prefix** and **suffix**. The actual file name is generated dynamically using the selected **File Cycle:** **file\_name = Prefix + Cycle + Suffix.** **File Naming Examples for different Cylcles** * **Prefix**: `log_` **Suffix:** `.csv` * **File Cycle Options** | File Cycle | Description | Example File Name | | ------------------------ | ----------------------------- | -------------------------- | | **None** | Single file | `log_.csv` | | **YYYY** | Yearly | `log_2025.csv` | | **YYYY\_MM** | Monthly | `log_2025_06.csv` | | **YYYY\_MM\_DD** | Daily | `log_2025_04_18.csv` | | **YYYY\_MM\_DD\_HH** | Hourly | `log_2025_04_15_05.csv` | | **YYYY\_MM\_DD\_HH\_NN** | Per minute (for testing only) | `log_2025_04_15_05_03.csv` | ### 4. File content In this section, you define the **format of each line** in the log file, including optional header text, timestamp placement, and variable encoding using a flexible text template. 1. **Optional File Header** * A one-time header line is added at the top **only when a new file is created** (e.g., on a new day or month depending on the file cycle). * Useful for column labels or unit information. * Can be left blank if not needed. 2. **Timestamp Format Selection** * Select the **TimeStamp format** from the dropdown. This determines the format that will be used when `#TS` is inserted into the encoder. * You can choose from UTC or Local time formats such as: * `YYYY-MM-DD HH:MM:SS` * `DD-MM-YYYY HH:MM:SS` * `UNIX_EPOCH` * `ISO 8601` * For a full list of available timestamp formats and codes (`TS_50` to `TS_66`), refer to the[ Time Stamp formats](https://docs.yudash.com/dc/df/pages/zVPbfkPk535M9wb3d1lP#h.t8n8abq6601b_l). 3. **Logger Text Encoder** * This is a simple, text-based encoder that defines how each line in the log file is written. This is of format TEXT\_FORMAT\_20 of [YuTGT](/device-to-cloud-api/payload-formats/yutgt-yudash-text-generator#yudash-text-generator-for-payload) * You can use: * **Single-character separators** such as `,`, `:`, `|`, , etc. * **Variable names** (e.g., `bod`, `tss`, `cod`) as defined in earlier configuration flows. These are replaced with their actual values during logging. * **Special `#` tags** to insert system-defined fields: * `#TS` → Timestamp (as per the selected format) * `#NL` → New line (typically added at the end of each encoder string to ensure proper row formatting) * Other #tags as per YuTGT * This flexible approach allows you to generate well-structured `.csv` or `.txt` files tailored to any downstream system. ## Example: Logging 4 Analog Channels with YuDash LYNX This example shows how to configure YuDash LYNX to log data from 4 analog input channels to the SD card using default settings. No Modbus devices or cloud connection is required. You’ll get one `.csv` file per day, which can be opened directly in Excel. ### Step 1: Load Example Configuration File To get started quickly, you can **load the ready-made lynx configuration json file:** {% file src="/files/6E8f95YcUHV6ouE78oNM" %} Simply download above json file and load into YuDash device. #### Step-by-Step Review of Settings Now let’s review what’s inside this file — based on screenshots and setting blocks: *** **✅ 1. Enabled Features**

In **LYNX Settings**: * `Analog Inputs`: ✔️ Enabled * `Data Logging`: ✔️ Enabled * `Ethernet/LAN`: ✔️ Enabled (for accessing logs via LAN browser) * Cloud/Network Server is set to "Offline" *** **✅ 2. Logging Frequency and RTC Settings**

In **Advance Feature Settings**: * `TimeSync Run (Minute)`: `1`\ → This tells the logger to save data every 1 minute * `Enable RTC`: ✔️ Checked * `Enable SDCard`: ✔️ Checked *** **✅ 3. Logger Settings (Default Mode)** *(See Screenshot 112)*

In **Data Logger Settings**: * `Use Default Settings`: ✔️ Enabled * All other fields: left empty > In this mode, the logger automatically: > > * Logs **all available analog inputs** (e.g., analog1 to analog4) > * Adds a **timestamp** at the beginning > * Uses **comma-separated CSV** format > * Saves one file per day in `/logger_dir` ### Step 2: Run LYNX with uploaded lynx.json Start by powering up the YuDash LYNX device with a microSD card inserted. * You **do not need to connect any analog sensors** at this stage. * LYNX will still log the 4 analog channels with default values (typically zero raw ADC readings). * Let the device run for a few minutes so it can generate at least 2–3 log entries. ### Step 3: View the File Created on SD Card After a few minutes of running, a log file will be created automatically on the SD card by the LYNX. * **Folder Path:** `/logger_dir` * **File Name Format:** ``` logger_file_YYYY_MM_DD.csv ``` For example: `logger_file_2025_06_12.csv` * **Sample File Content (this example has analog inputs connected, with 5,10,15,20mA at inputs):** {% file src="/files/buM6olJrtrb9n23IzB0W" %} ## Retrieval of data logger files in laptop/PC

The data files created by the YuDash logger on the SD card can be easily accessed using a laptop or desktop system. Follow the steps below (also illustrated in the image): 1. **Remove the SD Card from the Logger** * Gently push the SD card using a non-metal tool (e.g., plastic tweezer) to release it from the slot on the YuDash device. 2. **Insert SD Card into Laptop** * Use the built-in SD card slot (if available), or a USB card reader as shown in the example. 3. **Browse the Logger Directory** * Once inserted, the SD card appears as a removable drive. * Navigate to the configured **logger directory** (e.g., `/loggerDir`) to view the generated log files. 4. **Open Files in Excel or a Text Editor** * The files (typically `.csv` or `.txt`) can be opened in applications like Microsoft Excel, Notepad, or any spreadsheet/data analysis software for review and further processing. > 📎 Tip: Ensure the logging cycle has completed (e.g., file has closed properly) before removing the SD card for reliable file reads. SD card file access # YuDash Axon **YuDash Axon** is the edge intelligence layer built into **YuDash IoT devices**, designed to preprocess data at the device level before forwarding it to the cloud or industrial systems. It enables real-time transformation, computation, and standardization of raw inputs from a wide range of sensors and instruments. This feature is available only in few part numbers. *** #### **Key Features of Axon** * **🧩** [**YuParse**](/dc/df/axon/parse)\ Extracts structured values from ASCII/text sensor outputs using pattern-based parsing. Supports flexible tokenized patterns (`#D1`, `#A2`, etc.) and maps them to named variables. * **➗ Calculator**\ Perform real-time computations using parsed or raw values. Supports arithmetic expressions like addition, multiplier and basic functions (`min()`, `abs()`, etc.) to derive synthetic values at the edge. # YuParse **YuParse** is a lightweight and efficient ASCII/text parser designed for real-time data extraction on the edge. It is a core component of the **YuDash Axon** processing engine and is optimized for structured sensor output from industrial instruments such as weather stations, weighing scales, and transmitters. YuParse uses a **pattern-matching approach** where users define a template string with token identifiers (like `#D1`, `#I2`, `#T`, `#A1`, etc.) to extract specific fields from continuous or formatted ASCII inputs. It is tolerant to inconsistent whitespace and supports both data capture and structural matching. YuParse simplifies the challenge of parsing vendor-specific ASCII formats by providing a flexible yet deterministic framework that decouples pattern logic from parsing code. It enables high-throughput, low-overhead data structuring — critical for scalable IIoT deployments. The values extracted by YuParse can be directly utilized in various downstream pipelines. Parsed fields can be published to MQTT or HTTP endpoints. Additionally, these values can be fed into YuDash’s built-in Modbus RS485 or TCP/IP server, enabling seamless SCADA or PLC integration. This makes YuDash a powerful edge converter — capable of translating vendor-specific ASCII outputs into json payloads or Modbus-readable registers. Following are the steps to use YuParse Engine: ### 1) Reading text data from RS485/RS232 device The reading of text data from RS485 (or RS232) port is handled as custom "Modbus" registers, as explained here. Refer to documentation of [String Read in RS485/RS232](/dc/df/modbus/string). The string is provided as input (inputVar) to YuParse engine which will be matched with "pattern" string. ### 2) YuParse Pattern This the pattern string which will be used to parse the inputVar. * YuParse matches the `inputVar` (ASCII string) against the provided **`pattern`**. * By default, whitespace is ignored during matching for both inputVar and pattern. Extra spaces, tabs, or inconsistent spacing do not affect parsing. For strict parsing of inputVar, there is an option (described later). * The pattern is composed of: * **Tokens** (e.g., `#D1`, `#A2`) used to capture values. * Tokens without a numeric index (e.g., `#D`, `#S`) are treated as **match-only** and **not stored** in the output. * **Static strings** (e.g., `TEMP=`, `RH=`, `(Gross)`) that must match exactly * **Matching is case-sensitive** for static strings (`TEMP` ≠ `temp`). * YuParse performs a **best effort left-to-right match**, allowing partial parsing when some fields are missing or invalid. * Parsing stops when: * The pattern is fully matched * Or the input string ends unexpectedly or mismatches


Pattern Element	Type	Stored?	Description
#D1, #D2	Decimal/Float	✅ Yes	Parsed as float
#I1, #I2	Integer	✅ Yes	Parsed as integer
#T1	Timestamp	✅ Yes	Epoch timestamp
#S1, #S2	String	✅ Yes	Any text until next whitespace
#A1, #A2	Alphanumeric	✅ Yes	Strictly alphanumeric (letters and digits only)
#Sx	String ending with fixed character	❌ No	Any text until a known character (x). x may be mostly a "," or "=" etc.
#D, #S, #A	Match-only	❌ No	Used for pattern alignment; parsed but not stored
#N	New line	❌ No	Match a new line (\n) or carriage return (\r).
Non-token word	Literal Match	❌ No	Must exactly match input, ignoring extra whitespace

| **Input String (inputVar)** | **YuParse Pattern (pattern)** | **Parsed Values** | | ---------------------------------- | ------------------------------- | ---------------------------- | | `TEMP=23.4 RH=65.2` | `TEMP=#D1 RH=#D2` | `D1=23.4`, `D2=65.2` | | `STATUS=(OK) VALUE=99.8` | `STATUS=(#A1) VALUE=#D1` | `A1=OK`, `D1=99.8` | | `Device=ABC TEMP=45.0 UNIT=C` | `Device=#A TEMP=#D1 UNIT=#S` | `D1=45.0` | | `Device=ABC TEMP=45.0 UNIT=C` | `#S=#A1 TEMP=#D1 UNIT=#A2` | `A1=ABC, D1=45.0 A2=C` | | `t=21.5 , humid=(64.2)%` | `t=#D1 , humid=(#D2)%` | `D1=21.5`, `D2=64.2` | | `(Gross) 125.67 kg (Tare) 5.00 kg` | `(Gross) #D1 kg (Tare) #D2 kg` | `D1=125.67`, `D2=5.00` | | `TEMP:23.4,HUMIDITY:55.6` | `TEMP:#D1,HUMIDITY:#D2` | `D1=23.4`, `D2=55.6` | | `S/N=SNX123 Value=7.89` | `S/N=#A1 Value=#D1` | `A1=SNX123`, `D1=7.89` | | `Sensor1=OK Pressure=102.56 mbar` | `Sensor1=#A1 Pressure=#D1 mbar` | `A1=OK`, `D1=102.56` | | `DATA: A23 B56 C99` | `DATA: #A1 #A2 #A3` | `A1=A23`, `A2=B56`, `A3=C99` | | `WSpd=5.2 Dir=NW Temp=21.3` | `WSpd=#D Dir=#A1 Temp=#D2` | `A1=NW`, `D2=21.3` | ### **3) Mapping Tags to Variable Names** After parsing the input string using the pattern, YuParse assigns values to temporary tags such as `D1`, `A2`, `S1`, etc. These tags must then be **mapped to user-defined variable names** to make them meaningful and usable in further processing. * Mapping is defined using the `tagArray` field in your configuration. * Each entry maps a **token tag** (e.g., `"D1"`) to a **custom variable name** (e.g., `"temperature"`). * These variable names are similar to other variables read by YuDash devices. They can be published to MQTT/HTTP or used in Modbus server (only for numeric numbers) ## YuDash JSON APIs for Axon ### 1) Enabling YuDash Axon * Axon must be **explicitly enabled** using `"axon": 1` * The `axonSettings` block is ignored unless Axon is active * **Axon is supported only on selected YuDash models** ```json "dotFourSettings": { ... "axon": 1, ... } ``` ### 2) YuParse Settings within axonSettings ```json { "dotFourSettings": { // ... other flags and features "axon": 1 }, "axonSettings": { "parseArray": [ { "inputVar": "sensor_string", "pattern": "TEMP=#D1 RH=#D2", "tagArray": [ { "tagName": "D1", "varName": "temperature" }, { "tagName": "D2", "varName": "humidity" } ] } ] }, // ... other settings like mqttSettings } ``` ### Syntax of the Json blocks

Key	Type	Description
`inputVar`	string	Name of the input variable holding the ASCII string to be parsed. This is typically read through Modbus module.
`pattern`	string	YuParse-compatible pattern using tokens like `#D1`, `#A1`, etc. This will be matched with the inputVar.
`tagArray`	array	List of mappings between token tags and output variable names.
`tagName`	string	The token ID from the pattern (e.g., `"D1"`, `"A2"`, `"T"`)
`varName`	string	Custom variable name to use in downstream logic, MQTT, Modbus, etc.

### Explanation of the json * `sensor_string` is assumed to be an ASCII input like: ``` TEMP=23.4 RH=56.2 ``` * The `pattern` uses tokens `#D1` and `#D2` to extract two decimal numbers * These are mapped to final variable names `temperature` and `humidity` via `tagArray` * These variables can then be used in the payload. ## **Whitespace-Sensitive Parsing** By default, YuParse **ignores all whitespace** (spaces, tabs, etc.) in the input string when matching against a pattern. To enable **strict whitespace matching**, set `"whiteSpace": 1` inside a `parseArray` block. #### 🔖 **Special Token for Whitespace-Sensitive Mode**

Token	Meaning	Notes
`#W`	Match any number of whitespace characters	Required only when `whiteSpace` is `1`

📌 **Note:** The `#N` (newline) token can be used in both whitespace-sensitive and default modes. Newlines are **not ignored**, even when general whitespace is ignored. #### 🧾 Example **of Whitespace Matching** ```json { "parseArray": [ { "inputVar": "sensor_data", "pattern": "VOLT=#D1 #W UNIT=V", "whiteSpace": 1, "tagArray": [ { "tagName": "D1", "varName": "voltage" } ] } ] } ``` *** ## YuParse Examples ### **1) Example#1** **Input String:** ``` tT=(24.5C) RH=(64.3)% ``` #### **YuParse JSON Configuration** ```json "axonSettings": { "parseArray": [ { "inputVar": "env_data", "pattern": "T=(#D1C) RH=(#D2)%", "tagArray": [ { "tagName": "D1", "varName": "temperature_c" }, { "tagName": "D2", "varName": "humidity_percent" } ] } ] } ``` ### **2) Example#2** **Input String:** ``` TEMP=22.3 RH=48.2 STATUS=OK ``` #### **YuParse JSON Configuration** ```json "axonSettings": { "parseArray": [ { "inputVar": "sensor_raw", "pattern": "TEMP=#D1 RH=#D2 STATUS=#A1", "tagArray": [ { "tagName": "D1", "varName": "temperature" }, { "tagName": "D2", "varName": "humidity" }, { "tagName": "A1", "varName": "status" } ] } ] } ``` ### 3) **Example: Parsing Vaisala WXT530 Output** **🧾 Sample Input String:** ``` Ta=24.7C RH=53.2% P=1007.3hPa Ws=2.3m/s Wd=180D ``` *** #### ⚙️ **Expected Output Variables:** ```json { "temperature": 24.7, "humidity": 53.2, "pressure": 1007.3, "windspeed": 2.3, "winddir": 180 } ``` *** #### **YuParse JSON Configuration** ```json "axonSettings": { "parseArray": [ { "inputVar": "vaisala_string", "pattern": "Ta=#D1C RH=#D2% P=#D3hPa Ws=#D4m/s Wd=#D5D", "tagArray": [ { "tagName": "D1", "varName": "temperature" }, { "tagName": "D2", "varName": "humidity" }, { "tagName": "D3", "varName": "pressure" }, { "tagName": "D4", "varName": "windspeed" }, { "tagName": "D5", "varName": "winddir" } ] } ] } } ``` ### 4) **Example:** YuParse supports parsing **multiple input strings simultaneously**, each potentially coming from different sensors or serial sources.\ To enable this, the configuration uses a **`parseArray` array**, where: * Each item in the array defines a **separate parsing block** * Each block specifies: * An `inputVar` (input string source) * A `pattern` to match * A `tagArray` to map captured values to usable variable names This design allows you to process **multiple ASCII inputs in parallel**, even if they come from different instruments or formats. *** #### 🧾 Input Strings * `env1_string`: ``` TEMP=23.4 RH=56.2 ``` * `env2_string`: ``` Ta=24.7C RH=53.2% P=1007.3hPa ``` *** #### JSON Configuration ```json "axonSettings": { "parseArray": [ { "inputVar": "env1_string", "pattern": "TEMP=#D1 RH=#D2", "tagArray": [ { "tagName": "D1", "varName": "temperature1" }, { "tagName": "D2", "varName": "humidity1" } ] }, { "inputVar": "env2_string", "pattern": "Ta=#D1C RH=#D2% P=#D3hPa", "tagArray": [ { "tagName": "D1", "varName": "temperature2" }, { "tagName": "D2", "varName": "humidity2" }, { "tagName": "D3", "varName": "pressure2" } ] } ] } } ``` *** #### **Resulting Output Variables** ```json { "temperature1": 23.4, "humidity1": 56.2, "temperature2": 24.7, "humidity2": 53.2, "pressure2": 1007.3 } ``` # Firmware # Firmware release notes ## YuDash V5.5 * Release date: 18 September 2025 * FTP enhancements * Generic string in case of error * Support of variable specific formatting (decimals in floating point numbers) * Payload Enhancements * Flexible JSON (JSON\_19) payload based on input format * Generic timestamp encoder besides standard timestamps * Support of Jal Jeevan Mission API servers * 250+ group register read. * Complex payload structure with boolean outputs and metadata * Available as licensed version. * Weather monitoring Features. * Available in LYNX80 and FELYX80 series * RS232, SDI12 and rain gauge ## YuDash V5.4 1. Release date: 26 June 2025 2. **YuDash Axon:** * [**YuDash Axon**](/dc/df/axon) is the edge intelligence layer built into **YuDash IoT devices**, designed to preprocess data at the device level before forwarding it to the cloud or industrial systems. * Includes [**YuParse** ](/dc/df/axon/parse)engine for generic string parsing based on tokens. * **YuCalc** : generic real-time calculation engine (planned in later release). * **YuDash Axon feature is license based feature available in specific premium models.** 3. Modbus Enhancements 1. Modbus/RS485 bank register read and output as string/JSON array. 2. Support of **instantMqtt** feature with non-persistant MQTT connection. Applicable for specific Government server. 3. Modbus RS485 coil write bugfix in Modbus server. 4. Payload enhancements 1. Support of metaData in JSON\_10 payload format. The key-value pairs in **metaData** block in payloadSettings will be passed to output payload besides telemetry data. 2. Support of parsing device data in all payload formats 3. 5. 6. grouped register read 1. Support of group modbus read and Added support to read up to 64 registers in a single group (instead of individual register reads) over Modbus/RS485. 2. This is implemented through `slaveType` encoding. 3. After the banked read, individual registers can be parsed using specific data types. 4. This enhancement improves Modbus response time and addresses limitations in certain field instruments. 7. Modbus/RS485 Master register bank read: 1. Up to 100 Modbus registers can now be read as a sin ## YuDash V5.3 1. Release date: 18 May 2025 2. Modbus/RS485 grouped register read 1. Added support to read up to 64 registers in a single group (instead of individual register reads) over Modbus/RS485. 2. This is implemented through `slaveType` encoding. 3. After the banked read, individual registers can be parsed using specific data types. 4. This enhancement improves Modbus response time and addresses limitations in certain field instruments. 3. Modbus/RS485 Master register bank read: 1. Up to 100 Modbus registers can now be read as a single string. 2. A maximum of three register banks can be read from the PLC. 3. Register values can be encoded in string as as: 1. 16-bit signed integers 2. 16-bit unsigned integers 3. Hexadecimal values 4. This feature is available in the JSON\_10 and TEXT\_21 payload format. 4. MQTT to Modbus Server enhancement 1. MQTT subscribe-to-Modbus-server (slave) functionality is now supported. 2. Supports mapping of up to 64 variables to Modbus registers (increased from 32). 3. Supported data types: 1. 16-bit signed intege 2. 32-bit floating-point 4. A notional “Modbus timeout” mechanism is added. If MQTT subscribe commands are not received for a set number of cycles, mapped values revert to a default value. 5. YuDash Setu Features are incorporated: 1. MQTT to Modbus write feature when YuDash is Modbus master. 2. yudm: YuDash device management APIs through dedicated MQTT topic. 6. TCP Parser enhancements 1. Support for upto 24 tags in TCP parser. 2. Support of "status" variable to identify working tags in TCP parser. This useful when multiple tags of same name are present. 7. Sub Firmware Versions: 1. V5.35: YuDash LYNX 2. V5.30: YuDash ZENYX ## YuDash V4.6 1. Release date: 14 November 2024 2. Enhanced Ethernet setup and retry feature to check ethernet link status. This is primarily applicable for on-premise and peer-to-peer communication. 3. SD card Data logging with "useDefaults" feature. 1. With useDefaults enabled, SD card logging will be enabled all parameters (maximum 16) with first column as timestamp. The logger file is created on per-day basis in directory "/logger\_dir". 2. User can provide partial settings and other parts will be taken as default. 4. Bugfix of variables clash when both Lan UI and Modbus server is enabled. 5. Support of upto 20 variables in Modbus server. 6. Support of upto 30 variables in LAN UI server. 7. Beta version of serverMode. 1. serverMode is applicable with timeSync feature along with YuDash device acting as Modbus server. 2. The input instruments are read continuously for real-time refresh to Modbus server. This is similar to loopDelay=0. 3. Data push to cloud and SD card logging is done as per timeSync value. 8. Sub Firmware Versions: 1. 4.62: YuDash LYNX 2. 4.60: YuDash ZENYX 3. 4.67Q: YuDash LYNX with Quectel 4G module. 4. 4.65Q: YuDash ZENYX with Quectel 4G module ## YuDash V4.5 1. Release date: 13 October 2024 2. Enhancement for SD card mounting error and retries. 3. Enhanced Modbus RS485 server to avoid read errors. 4. Sub Firmware Versions: 1. 4.52: YuDash LYNX 2. 4.50: YuDash ZENYX 3. 4.57Q: YuDash LYNX with Quectel 4G module. 4. 4.55Q: YuDash ZENYX with Quectel 4G module ## YuDash V4.4 1. Release date: 1 August 2024 2. Support of SSL/TLS in MQTT and HTTP communication. 3. Firmware upgrade feature over local WiFi (OTA). 4. Improved SD card interface through repeated mounting attempt at bootup. 5. Improved configuration UI. Assets files can be browsed and updated. 6. Sub Firmware Versions: 1. 4.42: YuDash LYNX 2. 4.40: YuDash ZENYX 3. 4.47Q: YuDash LYNX with Quectel 4G module. 4. 4.45Q: YuDash ZENYX with Quectel 4G module ## YuDash V4.2 1. Release date: 8 May 2024 2. Support of LAN based configuration server and device monitoring. 3. Advanced text payload encoder. 4. Generic FTP support for text/CSV payload and file name. 5. High precision 16bit 8 channel ADC (Analog to digital converter) for LYNX. 6. Data logging on local SD card in generic CSV/text file format. This logging is independent of cloud payload. 7. Sub Firmware Versions: 1. 4.22: YuDash LYNX with 16 bit ADC 2. 4.20: YuDash ZENYX ## LYNX V3.9 1. Release date: 23 January 2024 2. Support of resetting to factory defaults in configuration page. 3. Support of SD card deletion from configuration parge. 4. Modbus RS485 with 115200 baud-rate through hardware Serial. 5. Two Register read in Modbus RS485 for single register read. varType of 60-69 has been added to support specific limitations in flow instrument. ## LYNX V3.7 1. Release date: 11 November 2023 2. Enhanced HTML parsing and tag search per updated [documentation](/yudash-iot-devices/lynx-user-manual/lynx-settings/html-parser-settings). 3. Support of DS18B20 temperature sensor. 4. Improved MQTT reconnect check to maintain connection with server. 5. Beta feature of MQTT to Modbus/RS485 slave (server). This acts as remote Modbus server. ## LYNX V3.6 1. Release date: 13 October 2023 2. Enhanced Modbus read support for 32 bit registers: 1. Support for byte swapped registers for LSB and MSB using 3 digit code. 2. Support for unsigned-int for 32 bit Modbus registers (code 24, 25) 3. Now YuDash IoT gateways support all byte swapping ([Modbus documentation](https://docs.yudash.com/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-rs485#h.jt0n9eorg4hg_l)) 3. Support for Float64 and Int64 register read in Modbus. This is subject to data handling at 32 bit during transmission. 4. Support for 8 channel analog in LYNX48 (V3.61) 5. Bug-fix in SD card read during NFH (network failure handler) operation. ## LYNX V3.5 1. Release date: 15 September 2023 2. Addition of JSON\_FORMAT\_16 payload format. * This is applicable for Indian OEM customer. 3. JSON\_FORMAT\_17 and JSON\_FORMAT\_18 * Generic two level JSON payloads with array (17) and JSON (18) 4. Improved reliability of temperature Digital Sensor DS18B20. 5. Firmware variant V3.51 for LYNX48 data logger with 8 channel analog inputs. ## LYNX V3.4 1. Release date: 2 August 2023 2. Improved HTTP/SSL support. ## LYNX V3.2 1. Release date: 16 June 2023 2. Addition of JSON\_FORMAT\_14 and JSON\_FORMAT\_15 1. Metadata at device level and variable level in JSON payload. 2. Variable mapping option in payload 3. Support of multiple cloud servers (upto 6 servers) for HTTP and FTP. 4. Addition of timestamp format: TS\_55 and TS\_65 (YYYY-MM-DD HH:MM:00) ## LYNX V3.1 1. Release date: 29 May 2023 2. Support of payload type XWWW\_FORMAT\_30 for *application/x-www-form-urlencode*d in HTTP/REST API Servers. 3. Improved watchdog timer. # Firmware upgrade # YuDash JSON API YuDash IoT devices have simple and innovative JSON based configuration mechanism. Effectively, all settings in configuration UI can also be done by editing of .json files. Basic understanding of [JSON ](https://www.w3schools.com/js/js_json_syntax.asp)syntax and format is required. JSON is primarily an hierarchical, key-value pair structure. While making any changes, please validate the syntax before saving the file. {% hint style="info" %} [jsonlint](https://jsonlint.com/) is a cool online JSON validator! {% endhint %} ## YuDash Configuration JSON: lynx.json This is main configuration file to control all functionality of IoT device. The file is typically internally stored lynx.json (for all devices) and downloaded to laptop with same name. It contains various JSON blocks which are parsed by YuDash IoT devices. Each block has a unique key (name) under which all relevant information will contain. **dotFourSettings** is primary block which controls most of top level functionality. In most of cases, presence of a given configuration settings does not enable a given feature. It has to be enabled (or disabled) using a flag in dotFourSettings (or applicable) block.. **The network settings (WiFi/4G/Ethernet) is not part of lynx.json. It has to be configured from YuDash configuration UI only.** ### **dotFourSettings** This is primary block of YuDash IoT devices which defines the feature (enable/disable) or configuration (enable/disable, numerical value). Minimal **dotFourSettings** example: {% code lineNumbers="true" fullWidth="false" %} ```json "dotFourSettings": { "modBus": 1, "loopDelay": "15", "cloudServer": 10, "displayName": "Thingsboard_demo", "dpPerPacket": "16" }, ``` {% endcode %} In a simple manner, above settings signify that 1. **modBus** : Modbus/RS485 is enabled and we need to read a modbus instrument as per settings in a block for modbus/RS485 protocol. 2. **loopDelay:** YuDash IoT device will have a loop cycle of 15 seconds. 3. **cloudServer**: data has to sent on a MQTT (10) broker as per provided MQTT settings. 4. **displayName**: YuDash IoT on-device display with show "Thingsboard\_demo". 5. **dpPerPacket**: is a configurable parameter which is set to 16. Most of the parameters are optional in nature with a default value. During downloading of a configuration from YuDash IoT device, the configuration engine auto-generates default values in json. For example, above file will be converted to below when downloaded from YuDash IoT device: ```json "dotFourSettings":{ "modBus":1, "loopDelay":"15", "cloudServer":10, "displayName":"Thingsboard_demo", "dpPerPacket":"16", "debugFlag":0, "anaToDig":0, "useDefaultCloud":0, "snmp":0, "modBusTcp":0, "ethernet":0, "rms":0, "rmsStoreData":0, "rtc":0, "sdCard":0, "nfh":0, "dataScale":0, "nwFallback":"0", "modBus2":0, "tcpParse":0, "sensor":0, "modBusServer":0 }, ``` dotFourSettings parameters for Feature Enable/Disable 0 is disable (typically default) and 1 is enable.

JSON key	Description
modBus	Read Modbus RS485 instruments. Blocks of modBusSettings and modBusSlaves defines protocol settings.
analToDig	Analog to Digital converter
snmp	Read SNMP data.
modBusTcp	Read Modbus TCP.
rtc	Run Inbuilt RTC
sdCard	Enable SD card.
nfh	Enable Network Failure Handler
debugFlag	Enable internal debug messaging of device. Enabling this flag slows down the IoT device. Keep it 0 for production runs.
useDefaultCloud	Use default cloud settings provided by YuDash. This is applicable for devices bundled with YuDash cloud features.
modBus2	Read 2nd channel of Modbus RS485. This is applicable for custom devices where dual channel RS485 is supported.

# Modbus Settings ## 1) Modbus/RS485 Settings ### modBus**Settings** Modbus Settings block for first channel of Modbus/RS485 {% code lineNumbers="true" %} ```json "modBusSettings": { "mbBaudRate": "9600", "mbParity": "1", "mbSlaveCnt": 1, "mbReadTryCount": "1", "mbHwSerial": 0 }, ``` {% endcode %}

JSON key	Description	Remarks
mbBaudRate
mbParity
mvSlaveCnt
mbReadTryCount
mbHwSerial

### modBus**Slaves** Modbus slaves information block for first channel of Modbus/RS485 ```json "modBusSlaves": [ { "slaveID": "1", "mbRegCnt": 1, "mbArray": [ { "varName": "MODBUS", "mbReg": "40004", "varType": "1", "varFactor": "1" } ] } ], ``` ## 2) Modbus TCP/IP Settings ## 3) Modbus RS485 Settings (Channel#2) ## 4) Modbus Server Settings # Analog Settings ## 1) Analog Input Settings anaToDigSettings Analog Input (4-20mA) input Settings {% code lineNumbers="true" %} ```json "anaToDigSettings": { "anaToDigCnt": 8, "anaToDigArray": [ { "anaToDigType": 1, "minOutVal": 0, "maxOutVal": 20, "minmA": 0, "maxmA": 20, "dcRes": 68, "varName": "VOC", "varName2": "VOC_MA", "varFactor": 1 }, // .. upto 4 or 8 channels //... { "anaToDigType": 1, "minOutVal": 0, "maxOutVal": 20, "minmA": 0, "maxmA": 20, "dcRes": 68, "varName": "A8", "varFactor": 1, "varName2": "" } ] }, ``` {% endcode %}

JSON key	Description	Remarks
anaToDigCnt
anaToDigType
minmA, maxmA
minOutVal, maxOutVal
varName
varName2
dcRes
varFactor

# Data Scale Settings ## 1) Data Scale Settings dataScaleSettings Data Scale Settings {% code lineNumbers="true" %} ```json "dataScaleSettings": { "scaleVariables": { "A1": { "minIn": 4, "maxIn": 20, "minOut": 0, "maxOut": 100, "minOutLimit": 0, "maxOutLimit": 100 }, // any number of output variables that needs scaling/clipping "A6": { "minIn": 4, "maxIn": 20, "minOut": 4, "maxOut": 20, "minOutLimit": 4, "maxOutLimit": 20 }, } }, ``` {% endcode %}

JSON key	Description	Remarks
scaleVariables
minIn, maxIn
minOut, maxOut
minOutLimit, maxOutLimit

### # YuDash IIoT Stack **IoT** involves flow of information from ***things*** (field instruments, PLC, sensor etc) to the **internet** (Cloud, local server, Edge device) . IoT Gateways/Data Loggers play a critical role in the flow of information across layers. **YuDash IIoT stack** in the figure below, explains various components of IIoT, which our products support. Different components of the stack will be explained in subsequent sections and Integration Guides.

YuDash IoT gateways (LYNX and ZENYX) can be easily integrated with any IoT platform on cloud. It can be integrated with on-premise server. This is enabled by flexible, no-code features. The IIoT stack is explained through the diagram below: ### [Multiple Cloud Protocols Support ](/device-to-cloud-api/cloud-protocols) * Support of MQTT and HTTP/S protocol (REST APIs) for connection to IoT platform. * YuDash IoT devices support FTP protocol for enterprise customers with legacy servers. Please contact us if you wish to add FTP support for your server. ### [Flexible Payload Formats](/device-to-cloud-api/payload-formats) * Flexible payload formats in JSON and TXT formats for smooth plug and play with servers. * Support of Time Stamp in payload with RTC enabled versions. * Support of backfill in server through flexible time formats to suit all platforms. * Besides process information, support of device status to monitor health of device. ### [Choice of Network Connectivity](/device-to-cloud-api/network-connectivity) * Choice of connectivity through 4G/LTE, Wi-Fi and Ethernet. Following are the main steps to connect to external IoT platform: 1. Selection of Cloud Protocol 2. IoT platform server details and credentials under Custom Cloud Server Settings in LYNX 3. Payload Format Selection # Cloud Protocols ### Introduction The parts of [YuDash IIoT Stack](/device-to-cloud-api/yudash-iiot-stack) covered in this section are shown below.

### Selection of Cloud Protocol in LYNX and YuDash IoT devices By default, YuDash LYNX is configured to connect to YuDash cloud. This is subject to tje purchase of YuDash cloud or YuReCon subscription. In such cases, "Use YuDash Cloud " is check marked. In this case, all custom cloud settings are ignored. LYNX will attempt to connect pre-configured device credentials to YuDash Cloud. For using external cloud (or on-premise) server, the applicable cloud protocol has been selected. **Following are the steps to select generic cloud protocol:** * Uncheck "User YuDash Cloud". This will disable use of YuDash cloud. * Select the **Custom Cloud** protocol: MQTT, HTTP or FTP

The offline mode is used when no cloud server is applicable. This is applicable for (a) YuDash IoT device as local logger, (b) on-premise remote display units (c) debugging and setup purpose with field instruments for Modbus. **Custom Cloud Settings** Details of cloud settings are filled in the sub-section below:

# MQTT MQTT is the most popular IoT cloud protocol. YuDash IoT device acts as MQTT client which sends data to various IoT platforms in a seamless manner. Two-way communication for receiving command from cloud is also available. **Following are the steps to use MQTT as cloud protocol.** ### Selection of MQTT As Cloud Protocol in YuDash IoT Device

### MQTT Credentials Following are the settings in LYNX to configure connection to MQTT server:

MQTT Setting	Description
MQTT Server (Broker)	The URL of MQTT broker is accessible on network. Alternately, unique IP address can be provided. This may be required for a local deployment.
MQTT Port	The IP port running MQTT server. Typically 1883
MQTT User name	Client user name for MQTT broker - Based on server, it may be blank or Access Tokens are used as user name.
MQTT Password	Client password for MQTT broker. Based on server, it may be blank or Access Tokens are given in password.
MQTT Client Name	Client name for MQTT broker. It may be simply blank is most cases, unless specified by server.
MQTT Publish Topic	The MQTT topic to publish data to. In many cases, it will contain and API name and may include unique serial number of device or variable.
MQTT Platform Name	MQTT Platform Name: Generic platform name. It is for information or display purpose only. It is not used in communication.

{% hint style="info" %} Depending on API and authentication mechanism in MQTT broker of IoT platform, some of entries may be blank. {% endhint %} Following is the example for MQTT integration with popular Tago.io IoT platform:

### MQTT with SSL/TLS secure layer YuDash IoT devices support SSL/TLS based secure communication. Please refer to [SSL/TLS for MQTT](/device-to-cloud-api/cloud-protocols/ssl-tls#enabling-ssl-tls-for-mqtt) documentation for enabling the security layer. # HTTP YuDash IoT devices support data push through REST POST API. Both HTTP and HTTPS (SSL) are supported. **HTTP** is the default TCP/IP protocol for cloud communication. YuDash LYNX supports POST REST API for sending data to HTTP Server. The HTTP headers can be configured to support various authentication types. Following are the settings in LYNX to configure connection to HTTP server:

HTTP Parameter	Description
HTTP Server	The URL of HTTP server is faccessible on the network. Alternately, unique IP address can be provided. This may be required for a local deployment. Remove any prefixes (http:// or https://) in the server name. Remove any suffix APIs from server name. They are provided in API below.
HTTP API	The API name (similar to subdirectory) which will accept POST request. This will typically start with "/".
HTTP Port	The port on which HTTP server is running.
HTTP Success Code	Success code REST API. This is used to check if POST command by IoT device was success or failure. This value has to be set as per cloud API.
HTTP SSL Enabled	Check this box for enabling HTTPS using SSL. This is recommended for production applications.

### **HTTP Headers for Authentication** 1. HTTP supports various authentication options. The authentication header keys and values are filled in section. * These are sent as HTTP headers to server for handshake. * The UI supports two headers. In case multiple custom headers are required, it can be configured in JSON configuration. ### Device headers with HTTP Payload In many HTTP servers, there may be single API accepting inputs from various sensors. So, it may be sharing credentials across a set of devices. In such cases, additional device information (say, machine name, sensorID, user-name) may have to be passed in JSON payload. This is besides the actual real-time data collected from sensors. For this requirement, there is an option to add device headers in JSON formats. ### SSL/TLS secure communication with HTTP YuDash IoT devices support HTTP with SSL/TLS secure communication. Refer to [SSL/TLS for HTTP ](/device-to-cloud-api/cloud-protocols/ssl-tls#ssl-tls-for-http)documentation. ## LYNX Display with HTTP Post Following are the typical LYNX display screens with HTTP POST

LYNX attempting HTTP POST to a given API on port 443

LYNX waiting for response from HTTP server

LYNX received HTTP response of 200, which matched with success code of 200

# FTP File Transport Protocol In general, [FTP ](https://en.wikipedia.org/wiki/File_Transfer_Protocol)(File Transfer Protocol) is an old protocol, not really suitable for IoT applications. But, there are many systems working on FTP for data logging. In principal, following are steps in file transfer in FTP: 1. Create a local file (typically text or CSV file) with a given name and text content. 2. Login to given FTP server (typically an IP address) using a login name and password. 3. Change directory at destination FTP server 4. Transfer the file from local device (YuDash IoT device) to FTP server ### Selection of FTP as cloud protocol in YuDash IoT Device

FTP is selected as cloud protocol in Cloud/Network Server

{% hint style="info" %} For custom cloud server, please ensure "Use YuDash Cloud" is **unchecked**. {% endhint %} ### Custom FTP Server Settings FTP settings are available within the **Cloud Settings** section. There are two sections in FTP settings, which are covered in following sections: 1. The FTP server details 2. The FTP file details (file name and content).

{% hint style="info" %} Similar to all sub sections, you have to click on "Read FTP Settings" to load present FTP Settings. After updating, please click on "Update FTP Settings". New FTP settings block will be created if not present earlier. {% endhint %} ### FTP Server Configuration FTP server includes following components:

Component	Description
FTP Server	The target FTP server, which is typically an IP address.
FTP User name	The user name for the given FTP server
FTP Password	The password to login to given FTP server
FTP Directory	The target FTP server directory where the payload fill will be uploaded by the YuDash IoT device.

{% hint style="info" %} It is advisable that FTP server credentials are verified using a FTP client PC software, for example [coreFTP](https://www.coreftp.com/). {% endhint %} ### FTP File Configuration After FTP server details are configured, next step is to configure the file which will be transferred to FTP server. There are two parts to it: 1. **File content**: The file will have text content with mix of telemetry, metadata and possibly timestamp. 2. **File Name**: We need to define the ***file name***, which will be created on given server directory. Typically, there a time stamp/snippet encoded in file name as we will uploading multiple files in same directory. {% hint style="info" %} YuDash don't support appending of file in FTP. A new file is created on the FTP server. Please contact us at if you have this requirement. We can surely do it, subject to business use-case! {% endhint %} There are two ways to create FTP files in the YuDash device. This is categorized by radio box **FTP File Type**". 1. **Default:** This is a default format which make a 3 line file with pre-defined file naming convention. This is used for a specific compliance server. 2. **Generic:** This is an extremely generic technique with flexibility of file name and content. In this case, file content is defined under payload setting. ### Generic FTP File Settings #### File Content in Generic FTP File Settings The file content of generic FTP File Type is defined under **Payload Settings.** Basically, the payload is the content of file, which can be technically a text or JSON payload. In most of cases, text payload will be used in FTP configuration. For this, powerful [YuTGT ](/device-to-cloud-api/payload-formats/yutgt-yudash-text-generator)(YuDash Text Generator) is used to generate any kind of text payloads with mix of telemetry, separators and device meta-data. Please refer [YuTGT TuDash Text Generator ](/device-to-cloud-api/payload-formats/yutgt-yudash-text-generator)documentation to get familiar with semantics. #### File Name is Generic FTP File Settings The file name itself is generated using the YuTGT. Following two settings are defined under "**Generic FTP File Settings**" 1. File Name Encoder: The input text to [YuTGT](/device-to-cloud-api/payload-formats/yutgt-yudash-text-generator) to create the **file name**. The file name is created using semantics of [YuTGT](/device-to-cloud-api/payload-formats/yutgt-yudash-text-generator). 2. File Name TimeStamp: The time stamp format (if required) to be used in the file name creation. This is similar to TimeStamp format used in [payload ](/device-to-cloud-api/payload-formats/json-payloads)settings.

### Generic FTP File Example We will explain the FTP file creation using an example. This uses [YuTGT Example#1](/device-to-cloud-api/payload-formats/yutgt-yudash-text-generator#yutgt-examples) for payload generation. File name encoder has following input ``` #YY #MM #DD #HH #NN #SS $_file.csv ``` Sample generated file and file name: **20240518101304\_file.csv** {% file src="/files/Kd8HpxelAt3t3nvoaBtR" %} ### FTP Troubleshooting guide In case of connection errors to FTP server for first time, please refer to following trouble shooting guide:

I am new to FTP. How do I start?

First and foremost, in case you are not able to connect to FTP server from YuDash IoT device, first connect to the server using FTP client PC software, for example [coreFTP](https://www.coreftp.com/). This will ensure that credentials and network access is correct.

I am not able to connect to FTP from my broadband (ethernet/WiFi) from YuDash or PC

FTP works on TCP/IP port 20 (data) and 21 (control). In many cases, these ports are disabled in router. Please enable these in your router settings. In most of cases of 4G/LTE network, we have not observed this problem. So, a mobile wifi hotspot based on 4G/LTE may be good option to try.

My PC client is working, but YuDash is not working

Please check FTP settings within YuDash. Few points to check: * Don't put any prefix (ftp\:// etc) in the IP address. * The FTP directory should start with slash / * Try some other network settings (WiFi/ 4G/Ethernet) * Ensure that target FTP directory has read/write access.

How to reach YuDash support

Please contact us on with your details. It is mandatory that FTP credentials are verified by customer through PC based client.

### # SSL/TLS YuDash IoT gateways supports SSL/TLS secure communication for MQTT and HTTP protocol. Following are typical steps to enable SSL/TLS security layer 1. Enable TLS/SSL within the cloud protocol settings. 2. Change the server port for TLS/SSL communication. 3. Upload server CA certificate in the IoT device. {% hint style="info" %} This documentation explains the TLS for CA signed server, which require a single pem file. For self signed TLS (involving pem, crt and key), refer to this [documentation](/device-to-cloud-api/cloud-protocols/ssl-tls/selfsigned). {% endhint %} ### **SSL/TLS for MQTT** 1\) Enable "SSL/TLS" radio button in **MQTT Secure Layer**. Change the **MQTT port** pertaining to secure layer of server. This is typically 8883 for MQTT.

2\) Upload server CA certificate to IoT device. First, **Choose File** and select the .pem file from local computer. Then, click on **Load SSL/TLS File** which will load the file in the browser. Finally, click on **Write SSL/TLS file**, which will write the the file into the IoT device.

3\) Following message is shown when CA certificate file is written successfully.

{% hint style="info" %} By default, the CA certificate for MQTT protocol is stored as file name /assets/mqtt\_cacert.pem within the YuDash IoT device. {% endhint %} ### **SSL/TLS for HTTP** 1\) Enable "SSL/TLS" radio button in **HTTP Secure Layer**. Change the **HTTP port** pertaining to secure layer of server. This is typically 443 for HTTP

3\) Following message is shown when CA certificate is written successfully.

{% hint style="info" %} By default, the CA certificate for HTTP protocol is stored as file name /assets/http\_cacert.pem within the YuDash IoT device. {% endhint %} # MQTT with Self Signed TLS This tutorial explains how to enable TLS security using **self-signed certificates** with YuDash products. To establish a secure connection with the MQTT broker, the client must present the following three files during the TLS handshake: * **CA Certificate** (`.pem`) – Certificate Authority file used to verify the server's certificate. * **Client Certificate** (`.crt`) – Identifies the YuDash device to the server. * **Client Private Key** (`.key`) – Used to prove ownership of the client certificate. To use self-signed TLS certificates with YuDash devices, you must upload the required files via the **Assets** section on the YuDash configuration page. {% hint style="info" %} Before configuring TLS settings on your YuDash device, it is **strongly recommended** to first verify the MQTT connection using a desktop client such as **MQTTX** (or any similar tool). This helps ensure that: * The server is accessible, * The self-signed certificates are valid, * The MQTT topic and credentials are correct. Once the connection works reliably on your PC/laptop, you can proceed to apply the same settings in the YuDash JSON configuration. {% endhint %} ## Connecting YuDash to AWS IoT Core via MQTT In this tutorial, we will walk through the process of configuring **YuDash devices** to connect with **AWS IoT Core** over MQTT. To ensure a smooth setup, we will first demonstrate the connection using the **MQTTX** desktop client as a reference. Once verified, the same configuration can be applied to YuDash via its JSON settings. ### **1) MQTT General Settings in MQTTX** MQTTX General Settings are filled with AWS IoT Core broker details. "CA or Self signed certificate" is selected.

### 2**) Certificates section in MQTTX**

### 3) MQTT Settings mapped to YuDash configuration The MQTT settings are per regular MQTT settings. MQTT Secure Layer is enabled. We will not select "MQTT CA Certificate" as we will use self signed certificates. These files will uploaded from Assets section (explained in next step).

### 4) Uploading Certificate files in YuDash through Assets folder

### 5) Mapping the uploaded certificate files in MQTT Settings After the certificate files are uploaded in the YuDash IoT device (/assets), the MQTT settings have to be manually updated in lynx.json file. Besides regular MQTT settings, the "tls\*" keys have to be inserted for mapping to certificate files.

### 6) Sample lynx.json for self signed certificate Following is sample mqttSettings block to use self signed certificate in TLS ```json // sample MQTT settings in lynx.json "mqttSettings": { "platformName": "AWS", "mqttSSL": 1, "mqttServer": "MQTT_broker_url", // as per server settings "userName": "", "password": "", "publishTopic": "", "clientName": "", "mqttTLS": 1, "tlsCaCert": "/assets/AmazonRootCA1.pem", // names as per uploaded files. "tlsClientCert": "/assets/AWS1.pem.crt", "tlsClientKey": "/assets/AWS1.pem.key", "tlsSetInsecure": 0, "mqttPort": "8883", }, ``` # Payload Formats ### Introduction [Payload](https://en.wikipedia.org/wiki/Payload_$computing$) is actual data containing sensor information, which is sent over given Cloud protocols. YuDash IoT edge devices have easy-to-use and flexible, no-code APIs to generate payloads. This provides simple integration with various IoT platforms. This is where Payload fits within the [YuDash IIoT Stack](/device-to-cloud-api/yudash-iiot-stack):

### Support payload Formats Some of supported formats are listed below: [JSON Format](#json-payloads) YuDash IoT devices support various formats of JSON to support various IoT platforms. [YuTGT](/device-to-cloud-api/payload-formats/yutgt-yudash-text-generator) (YuDash Text Generator) for TXT/CSV files Generic TXT/CSV payload can be generated using [YuTGT](/device-to-cloud-api/payload-formats/yutgt-yudash-text-generator) YuDash Text Generator. These are suitable for IoT platforms supporting CSV formats, FTP/file based data. Besides, main sensor data, YuDash devices support different TimeStamp options. Also, device status and diagnostics information transmission to cloud is supported. # JSON Payloads YuDash [LYNX](/yudash-iot-devices/lynx-user-manual) and other IoT Devices support the following JSON payload formats of payload. Each format has a unique number (starting with 10). We explain each JSON format with an example of energy monitoring: * There are three process variables/tags. Voltage, frequency and energy, namely: **volt1\_in** **freq\_in** and **kwhr\_in** * Numerical values (floating points) are read by LYNX for reach variable. * There is a string variable **status\_var1** which is used to capture device status information. This is an optional variable in which LYNX sends in device information at bootup and periodically. * The variable names for device information are treated just like process variables. * The timestamp variables are processed as per the given JSON format. It is a purely optional parameter and should only be used when back-fill feature is required. * LYNX has two user provided input strings (Payload Gen Key#1 and Payload Gen Key#2). We will call them **`plKey1`** and **`plKey2`**. ## JSON PAYLOADS ### JSON\_FORMAT\_10 * This is the simplest JSON format with key value pairs. * plKey1 and plKey2 are not used. **Sample payload format** ``` { "volt1_in": 237.67, "freq_in": 49.98, "kwhr_in": 1792.17 } ``` **Status Variable Payload** ``` { "status_var1":"LYNX rebooted. count=7700. reason=0" } ``` ### JSON\_FORMAT\_11 * This is a two level JSON format with variable names as main key. * **plKey1** is not used. **plKey2** is used. This is set as "**value**" in the example below. **Data payload format** ``` // JSON_FORMAT_11 { "volt1_in": { "value": 244.4 }, "freq_in": { "value": 50 }, "kwhr_in": { "value": 1792.17 } } ``` ### JSON\_FORMAT\_12 * This is a JSON array with data points for each variables. * **plKey1** is used (set to field in example). **plKey2** is used and set as value in the example below. **Data payload format** ``` [ { "field": "volt1_in", "value": 242.34 }, { "field": "freq_in", "value": 49.92 }, { "field": "kwhr_in", "value": 1792.17 } ] ``` **Status Variable Payload** ``` [ { "field": "status_var1", "value": "status: RSS: -60 db, wifi_name: ***, wifi_ip:***" } ] ``` ### JSON\_FORMAT\_13 * This is a two level JSON structure. * **plKey1** is used (set to data in example). **plKey2** is not used. **Data Payload** ``` { "data": { "volt1_in": 241.65, "freq_in": 49.99, "kwhr_in": 1792.17 } } ``` **Status Variable Payload** ``` { "data": { "status_var1": "status: RSS: -62 db, wifi_name: ***, wifi_ip:###" } } ``` ### JSON\_FORMAT\_14 and JSON\_FORMAT\_15 * These are proprietary JSON formats for Indian State Pollution control Board. ### JSON\_FORMAT\_16 * Proprietary JSON payload for Indian OEM customer. ### JSON\_FORMAT\_17 and JSON\_FORMAT\_18 * Generic two level JSON payloads with option of array (FORMAT\_17) and json (FORMAT\_18). ## TimeStamp Formats LYNX supports the following timestamp formats to send to cloud server when timestamp has been enabled. The time displayed on YuDash LYNX is local time (based on time-zone provided). In most cases, it is advised to store/send UTC time stamps. ### UTC Time Stamp Formats | Time Stamp Format | Sample Time Stamp | | ------------------------------------- | ------------------------------------------- | | TS\_50 (UTC Seconds) | 1675630526 | | TS\_51 (UTC MilliSeconds) | 1675630526000 | | TS\_52 (UTC YYYY-MM-DDTHH:MM:SS) | 2023-02-05T20:55:26Z | | TS\_53 (UTC YYYY-MM-DD HH:MM:SS) | 2023-02-05 20:55:26 | | TS\_54 (UTC YYYY\_MM\_DD\_HH\_MM\_SS) | 2023\_02\_05\_20\_55\_26 | | TS\_55 (UTC YYYY-MM-DDTHH:MM:00) | 2023-02-05 20:55:00 *(seconds taken as 00)* | | TS\_56 (UTC DD-MM-YYYY HH:MM:SS) | 05-02-2023 20:55:26 | ### Local Time Stamp Formats

Time Stamp Format	Sample Time Stamp
TS_60 (LocalTime Seconds)
TS_61 (LocalTime MilliSeconds)
TS_62 (LocalTime YYYY-MM-DDTHH:MM:SS)
TS_63 (LocalTime YYYY-MM-DD HH:MM:SS)
TS_64 (LocalTime YYYY_MM_DD_HH_MM_SS)
TS_65 (LocalTime YYYY-MM-DDTHH:MM:00)
TS_66 (LocalTime DD-MM-YYYY HH:MM:SS)

The time stamps are sent along with Time Stamp Key (**tsKey**). They are grouped in within json format depending on JSON\_FORMAT\_. The timestamp key is set as timestamp in all the examples. Typically, based on server requirement timestamp, ts or time keywords are used. JSON\_FORMAT\_10, TS\_50 ``` { "volt1_in": 247.55, "freq_in": 49.94, "kwhr_in": 1792.17, "timestamp": "1675630887" } ``` # YuTGT: YuDash Text Generator YuDash Text Generator YuDash Text Generator is a powerful engine to generate any kind of text payload in flexible manner including the telemetry, metadata and timestamps. YuDash Text Generator is primarily used to generate text ### YuDash Text Generator for Payload The YuDash Text Generator is primarily for payload generator, which is explained here. It is also used in FTP file name creation, and local data logging. The semantics for engine remains same. ### Payload Settings 1. Select the payload Format of "TEXT\_FORMAT\_20" to use YuTGT. 2. Select the timestamp format to be used in Text Generator. 3. The configuration to YuDash Text Generator

### YuDash Text Generator Block The YuTGT block contains the series of encoding block (string) to generate the output payload text. Each string is separated by blank space(s). The complete block is processed by YuTGT engine to generate the text payload in every run-cycle. #### YuTGT String components

Encoding String	Description
$meta_data	The string prefixed by $ is encoded as it is in the output text (with $ removed). It is used to encoder any meta_data in the output text.
Single character	A single character (probably , . # etc) is encoded as it is in the output text. This simplifies creation of CSV without cryptic encoding. It is assumed that variable names are at least 2 characters!
#AA Encoder	The string prefixed with an # followed by 2 capital letters are used to encode specific data-times and special characters.
#TS	The timestamp as selected in payload settings will be encoded in the text. It can be UTC or local-time as per selection in Time-Stamp Settings.
#YY	Year encoded as 4 digits. This is taken from local-time.
#MM	Month encoded as 2 digits. This is taken from local-time.
#DD	Date encoded as 2 digits. This is taken from local-time.
#HH	Hour encoded as 2 digits. It is taken in 24 hour cycle from localtime.
#NN	Minutes encoded 2 digits. It is taken from local-time. Please note that minutes is #NN (not #MM, which used in month).
#SS	Seconds encoded as 2 digits. It is taken from local-time.
#DT	Date is format YYYY_MM_DD in encoded. It is taken from local-time.
#TD	TimeOfDay of format HH_NN_SS is encoded.
#NL	New line character. Please use #NL at end if you need and newline after text. Also, this is used to create a multi-line text file.
#SP	A black space is generated in the output text.
normal_string	A normal string is one without a prefix (a $ or an #) and at least 2 character long. This is looked up in the variables of payload and replaced with the actual value. Notes: a) For example, a temperature variable read from modbus written as 234.56 in the output text. The numbers are written as 2 decimal digits as default. b) In case the normal_string is not found in the variable list, it is ignored and no output text will be generated. c) In case, there was an error associated with reading of given variable (say modbus read error), the error string can be encoded in the output. It has to be specified in JSON configuration (not available in UI)

## YuTGT Examples Let's understand the YuDash Text Generator by actual examples. In all the examples, we are reading temperature and humidity from XY02 modbus sensor which are read as **temp** and **humid** in Modbus Settings. #### YuTGT Example#1 Input YuDash Text Encoder Block ``` #YY / #MM / #DD , #HH : #NN : #SS , temp , humid , #NL ``` Output Text payload ``` 2024/05/18,10:13:04,38.50,27.70, ``` Explanation * \#YY #MM and #DD are replaced with present date. They were encoded with / in between. * \#HH #NN #SS was the time block, which were encoded with : in between. * The **temp** and **humid** values as read from Modbus sensor were encoded with comma separators. * Finally, **#NL** adds a newline to the output file. #### YuTGT Example#2 Input YuDash Text Encoder Block ``` $date , $temp , $humid #NL , $celcius , $percent #NL #TS , temp , humid , #NL ``` Output Text payload ``` date,temp,humid ,celcius,percent 2024_05_18_11_12_12,38.70,27.80, ``` Explanation * $date $temp $humid strings are encoded as raw string (meta) data. * \#NL is used to create multiple line file with new lines between 3 parts. * \#TS is used to generate a fixed time stamp format. Timestamp format of TS\_64 has been selected in TimeStamp section to generate given time stamp. * The actual value of temp and humid were encoded in the output text. # Network Connectivity ### Introduction Network Connectivity refers to physical layer of connectivity on which IoT device will communicate. This is how it fits within the [YuDash IIoT Stack](/device-to-cloud-api/yudash-iiot-stack):

### Supported Network Connectivity YuDash IoT devices support various network connectivity options for different IIoT solutions.

Network Connectivity	Typical Use-Cases.
4G/LTE	Standalone IoT connectivity through SIM card. This provides a reliable connectivity without any external dependies.
Ethernet	a) IoT gateway connected to Internet enabled LAN. b) IoT coupled with 4G/LTE router. c) IoT gateway connected to LAN with local/on-prem server.
WiFi	a) IoT gateway connected to Internet enabled LAN through WiFi. b) IoT coupled with 4G/LTE Wifi router. c) IoT gateway connected to LAN with local/on-prem server. It is important to have a strong Wi-Fi for a reliable connection
LoRaWan	YuDash IoT devices do not support LoRaWan at present.

[Network Settings](/yudash-iot-devices/lynx-user-manual/network-settings) of YuDash LYNX manual covers documentation for network connectivity. # Industrial Protocols ### Introduction Industrial protocols are used for the communication of various industrial/field instrument with each other. YuDash IoT devices support various industrial protocols to read data from Instruments, Indusial PLC/Assets, Environment sensors etc. This covers major part of [YuDash IIoT Stack](/device-to-cloud-api/yudash-iiot-stack):

### Supported Industrial Protocols YuDash IoT devices support various industrial protocols. Please refer to

Industrial Protocol	Details and References
Modbus/RS485	This is one of the most popular serial protocol for industrial applications like Energy/Power, Process Control. The documentation is covered within LYNX User Manual. Integration with popular RS/485 devices is covered in Industrial Equipment Integration Guide.
Modbus TCP/IP	Modbus TCP/IP is a popular protocol with PLC/HMI and advanced machine. It uses the simplicity of Modbus, along with reliable TCP/IP network. Modbus TCP/IP section of YuDash LYNX user manual provides necessary documentation.
Analog Inputs	Analog inputs include 0-20mA, 0-10V devices. YuDash LYNX Data Logger supports 0-20m Analog input. The analog documentation along with data scaling feature is covered in LYNX user manual. For higher channels (or 0-10V DC), one can use various instruments, as covered in process control integration guides.
HTML Parsing	Many legacy instrument and environment analyzers have on-board local-web server. There is no industrial procotol available to communicate. YuDash LYNX provides flexible HTML Parsing feature to extract data from local web-server over ethernet!
Digital Sensors	Latest instrumental sensors use digital protocols like I2C, Two Wire protocols, instead of 4-20mA. This ensures an accurate process. These are documented in Digital Sensors Section of LYNX User Manual
SNMP	SNMP (Simple Network Management Protocol) is typically used for LAN based management. YuDash supports SNMP to read industrial assets (eg: UPS)

# Modbus Modbus for connecting IoT Gateways with instruments Modbus is one of the most popular serial protocol for industrial systems. It is used for data exchange between sensors, instruments, PLC, HMI and parts of SCADA system. Please refer to [Wikipedia](https://en.wikipedia.org/wiki/Modbus) and [official standard](https://modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf) for technical details. With advent of IIoT, IoT gateways communicate with various components over Modbus. This documents various topologies of Modbus based systems. ## Modbus Communication Concept Modbus works on the concept of **Master** and **Slave.** The master sends a **request** to slave and slave **reply** with required information. {% hint style="info" %} These words have been [officially](https://modbus.org/docs/Client-ServerPR-07-2020-final.docx.pdf) replaced to **Client** *(Master)* and **Server** *(Slave).* Unfortunately, Master/Slave words still remain popular in industry (at least for Modbus/RS485). In Modbus TCP/IP, Client-Server is more prevalent. For ease of understanding, we use unofficial words in this tutorial. {% endhint %} ## Modbus Versions Following are two popular version of Modbus which are supported by YuDash IoT devices. #### 1) Modbus/RS485 (or Modbus/RTU) * Refer to [Modbus Settings in LYNX User Manual](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-rs485). * Integration with RS/485 devices in [Industrial Equipment Integration Guide](/integration-guides/industrial-instruments). * [Modbus RS485](/dc/df/modbus) in YuDash Device Features * [Modbus Poll Tutorial](/dc/df/modbus/modbus-poll-tutorial) in YuDash Device Features #### 2) Modbus/TCP-IP * Refer to [Modbus TCP/IP](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-tcp-ip) in LYNX User Manual With assumption of basic Modbus understanding, we explain integration of YuDash IoT devices with Modbus instruments, PLCs and HMIs. ## Integration of IoT Gateway in various Modbus topologies ### 1) Integration of IoT Gateway with PLC based systems #### 1) Typical PLC application with Modbus/RS485 communication

#### 1A) PLC system with IoT Gateway using Modbus/RS485

#### 1B) PLC system with IoT Gateway using Modbus TCP/IP

### 2) Integration of IoT Gateway with PLC+HMI based systems #### 2) Typical PLC+HMI based system

#### 2A) PLC+HMI with IoT Gateway using Modbus/RS485

#### 2B) PLC+HMI with IoT Gateway using Modbus TCP/IP

### 3) IoT Gateway with RS485 enabled instruments

All Modbus topologies are captured in below tutorial {% file src="/files/IUA5SxqUPeJDKcCLyzM5" %} ## Requirements in PLC system for IoT compatible It is important that PLC based system for Industrial Machines/Assets are designed to be IoT compatible. It is imperative that all machines will be IoT enabled (Industry 4.0) now or later in future. Following are key requirements during system design to make IoT ready (using Modbus): 1. Identify existing topology of PLC/HMI system from [above](#integration-of-iot-gateway-in-various-modbus-topologies) list and select one of integration option for IoT Gateway. 2. One channel of Modbus RS485 or Modbus TCP/IP (Ethernet) has to be made available for IoT gateway. IoT Gateway will be Modbus Master (Client) which will request data from the existing system. 3. The select Modbus channel has to be configured as Slave (Server) and communication settings should be well documented. 4. Following is required information for **Modbus RS485**:

RS485 Parameter	Sample/Description
Baudrate	9600, 19200 etc
Data Bits, Parity & Stop Bit	8N1, 8E1 etc.
Slave ID for Modbus slave	1, 2 etc.
Modbus RS485 terminals	The RS485 terminals should be well defined (preferably take a photograph with A and B marked). In case of DB9/RJ25/RJ45 jack, clearly identify the pins. It is advisable to provide a two wire connector on the jack.

> It is advisable that provided communication settings should be verified by PC based Modscan software. Please document snapshots of Modscan, similar to this [example](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-rs485). 5. Following is required information for **Modbus TCP/IP** | Modbus TCP/IP Paramter | Sample/Description | | ------------------------------------- | -------------------------------------------------------------------------------- | | IP address | 192.168.100, 10.0.0.1 etc. | | IP port | The port number on which Modbus Server is running. For example: 503, 888 | | Server ID Modbus Server | 1, 2, etc. | | RJ 45 jack for connecting IoT gateway | Well defined RJ45 jack to connect IoT Gateway. It can be in PLC/HMI or a switch. | 6. Identify critical parameters from the system to be provided to the IoT Gateway. These can be real-time process values, thresholds, batch numbers or alarm values. 7. List down the parameter names, Modbus register numbers, data types in tabular form. 1. The register should be complete 5 digits or define the register type (Input, Holding etc). 2. If data type is Floating point, please define LSB/MSB type. 8. Sample Table of Modbus Registers | Parameter | Modbus Register | Data Type | | ----------- | --------------- | -------------------- | | Voltage | 40000 | Signed Integer | | Temperature | 30050 | Floating point (LSB) | | Alarm1 | 10000 | Binary | ### Technical References for YuDash IoT Gateways 1. [Modbus RS485 Settings in YuDash LYNX](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-rs485) 2. [Modbus TCP/IP Settings in YuDash LYNX](/yudash-iot-devices/lynx-user-manual/lynx-settings/modbus-tcp-ip) 3. [Instrument Integration Guides with YuDash LYNX](/integration-guides/industrial-instruments) # YuDash IoT Platform Besides IoT Gateways and Data Loggers, YuDash offers [YuFourIA ](https://yufouria.yudash.com/)IoT platform. It is offered as a SaaS based model. ## YuDash IoT Platform Login Page

{% hint style="info" %} Please refer to our [YuDash IoT Platform Page ](https://www.yudash.com/products/yudash-iot-platform)for sample dashboards. Please email us at for end-to-end IoT solution. {% endhint %} ## YuReCon [YuReCon ](#yurecon)(YuDash Remote Configuration) is a powerful cloud based tool to remotely configure the LYNX IoT Gateway. It is built over YuDash IoT platform and is offered as a value added service. # YuReCon YuReCon (YuDash Remote Configuration) is a powerful cloud based tool to remotely configure the LYNX IoT Gateway. It is built over YuDash IoT Platform and is offered as a value added service. When YuDash IoT Platform services are used, YuReCon is automatically enabled at the backend. The front-end access is enabled at nominal charges. {% hint style="warning" %} It is mandatory that IoT device should be powered ON, connected to internet and YuReCon settings enabled. {% endhint %} ## YuReCon with External Cloud Platforms With flexible architecture, YuReCon service can be used in conjunction with any other cloud platforms. The following diagram explains overall architecture. * Remote device configuration * Device health and status * Optional data backup on YuDash IoT platform.

When YuReCon is enabled, the YuDash IoT device communicates with YuDash platform for two-way communication. {% hint style="info" %} Customer data is stored **NOT** stored on YuDash Cloud. YuReCon is used only for device management through two way MQTT {% endhint %} ## YuReCon for Data Backup YuReCon can also be used to utilize YuDash Cloud as data backup along with external IoT platform. In this case, YuDash IoT devices will send process data to external IoT platform/server and also to YuDash platform. ## YuReCon Dashboard YuReCon dashboard is similar to local Wi-Fi configuration of YuDash IoT devices. It is available with YuDash YuFourIA cloud platform. Steps to Use YuReCon 1\) Select the target device that you want to access 2\) Send a **Request** to YuDash IoT device. 3\) Check "Read Information" for device response. Dashboard is populated with device information on successful response. In case there is no response from device (either it is inactive or busy), popup message will be shown.

4\) After making changes, **Remote Write Command** is issued to update the device settings. This is similar to write command on local Wi-Fi configuration.

5\) Similar to local Wi-Fi Configuration, the changes of YuReCon require device reboot. For this purpose, **Remote Reboot LYNX** is used. ## Important Notes For Using YuReCon * YuReCon is primarily designed for tweaking and configuring deployed devices. * As a part of design consideration, network settings are not permitted to be changed by YuReCon. It is assumed that the network settings (be it 4G/LTE, Ethernet) etc have been setup during installation. Also: In case network settings are mis-configured (say, a wrong 4G setting or network more), the device will not connect to network after reboot. In such case, it has to be physically accessed by user for re-configuration. * YuReCon communicates with YuDash IoT devices while they are running field. So, the response will depend on load on the device. In cases of high Modbus registers, or slow network or cloud server (say FTP/HTTP), YuRecon would have slow response. * Patience and understanding of device behaviour is required for effective use of YuReCon. We don't claim VNC or AnyDesk type of performance! * JSON upload/download feature is a useful way to use YuReCon. This way, all settings can be changed locally and only updated settings are "uploaded" to device remotely. # IoT Platform Integration YuDash believes in co-innovation, partnerships and ecosystem. We partner with global IoT platforms. YuDash IoT Gateways and Data-loggers are seamlessly integrated with various enterprise platforms through various cloud protocols. This section covers integration of YuDash IoT devices with various IoT platforms: ### [Ubidots](/integration-guides/iot-platform-integration/ubidots) ### [TagoIO](/integration-guides/iot-platform-integration/tagoio) ### [Losant](/integration-guides/iot-platform-integration/losant) ### [DataCake](/integration-guides/iot-platform-integration/datacake) ### [Eagle.io](/integration-guides/iot-platform-integration/eagle.io) ### [Boodskap](/integration-guides/iot-platform-integration/boodskap) ### [Statstream](/integration-guides/iot-platform-integration/statstream) ### [Qubitro](/integration-guides/iot-platform-integration/qubitro) ### [Thingsboard](/integration-guides/iot-platform-integration/thingsboard) # Ubidots [Ubidots](https://industrial.ubidots.com/accounts/signup_industrial/?via=yudash) is a leading Industrial IoT platform. Industrial companies use Ubidots IoT software to launch beautiful web and mobile applications for Condition Monitoring, Smart Manufacturing, Cloud SCADAs, Vibration Analysis, and more. YuDash is [IoT hardware partner](https://partners.ubidots.com/dl/74c4fe/s/6f72ad/r/InyokPmgQ7q9OhwtT6MVKg) and [Certified Solution Partner](https://partners.ubidots.com/dl/74c4fe/s/6f72ad/r/d.HFZVaaTR-kDWyUWbcAFQ) of Ubidots IoT platform. YuDash IoT devices are being widely used with Ubidots worldwide. ## YuDash LYNX to Ubidots IoT Platform The integration of YuDash LYNX with Ubidots IoT platform is available on Ubidots website. {% embed url="" %} The steps are also explained in the video below. An energy meter is read and data sent to Ubidots IoT Platform. {% embed url="" %} Please refer to [YuDash Ubidots partner page](https://www.yudash.com/partners/ubidots) for latest updates and use-cases. # TagoIO [TagoIO](https://tago.io/) offers an end-to-end platform that transforms how businesses create value from connected products and user interactions. Unlike other providers that demand high-level skills to create a solution, TagoIO requires minimum effort for setup and operation. Under the PaaS model, TagoIO provides all the functionalities to perform: device management, data storage, real-time data visualization, user management, custom analytics, and notifications. YuDash is hardware [partner](https://tago.io/partners) and System Integrator of TagoIO. YuDash LYNX is certified [Integrated device](https://tago.io/devices) ### YuDash LYNX to TagoIO IoT Platform The integration of YuDash LYNX with TagoIO IoT platform is explained through the video. An energy meter and analog input source is read and data sent to TagoIO IoT platform through MQTT. {% embed url="" %} Please refer to respective documentation for specific details. * [Device creation in TagoIO](https://help.tago.io/portal/en/kb/articles/166-adding-devices-with-connectors) * [Device Token in TagoIO](https://help.tago.io/portal/en/kb/articles/4-device-token) * [TagoIO MQTT Broker Details](https://help.tago.io/portal/en/kb/articles/32-mqtt) # Losant Losant is an easy-to-use and powerful enterprise IoT platform designed to help teams quickly and securely build complex real-time connected solutions. Losant uses open communication standards to provide connectivity from one to millions of devices and provides powerful data collection, aggregation, and visualization features to empower enterprise teams with new data insights. Edge features are integrated directly into the Losant IoT platform for seamless integration of connected and non-connected devices. Start independently or work with Losant’s experienced solution engineers. ## YuDash LYNX to Losant IoT Platform The integration of YuDash LYNX with Losant IoT platform is explained through the video. An energy meter and analog input source is read and data sent to Losant IoT platform. {% embed url="" %} . Please refer to respective documentation for specific details. * [Device creation in Losant](https://docs.losant.com/devices/overview/) * [Device Attributes in Losant](https://docs.losant.com/devices/attributes/) * [Losant MQTT Broker](https://docs.losant.com/mqtt/overview/#the-losant-message-broker) # Datacake Datacake is a multi-purpose, low-code IoT platform that requires no programming skills and minimal time to create custom IoT applications that can be brought into a white label IoT solution at the push of a button. YuDash is hardware partner and system integrator of Datacake. YuDash LYNX is easily [integrated ](https://docs.datacake.de/integrations/yudash-lynx-iot-gateway)into Datacake as per below documentation. {% embed url="" %} # Eagle.io [Eagle.io](http://eagle.io/) is a cloud environmental data management platform. It offers data acquisition, storage, and visualization capabilities that enable users to easily monitor and manage environmental data in real-time. Eagle.io is designed to work seamlessly with a wide range of gateways, and environmental sensors, including the [YuDash LYNX logger](https://docs.eagle.io/en/latest/topics/device_configuration/yudash/index.html). The platform's user-friendly interface empowers non-technical users to easily create custom dashboards, analyze data trends, and set alerts. With robust data security and reliability features, Eagle.io is trusted by fortune 500 organizations and government departments around the world to monitor and manage their environmental data. ## YuDash LYNX Data Logger With Eagle.io YuDash LYNX Data Logger is fully integrated with Eagle.io catering to various [Environment compliance and ESG](https://www.yudash.com/iot-solutions/environment-compliances) use cases. Please refer to Eagle.io [documentation](https://docs.eagle.io/en/latest/topics/device_configuration/yudash/index.html) for device integration steps. {% embed url="" %} # Boodskap [Boodskap](https://boodskap.io/) is the most complete IoT Platform which is reliable, scalable, and secure. With comprehensive end-to-end technology serving Fortune 500 clients, Boodskap has created a powerful and simple self-serving IoT platform with capabilities ranging from device agnostics to streaming data and building complex applications. ## YuDash LYNX To Boodskap IoT platform The integration of YuDash LYNX with Boodskap IoT platform is explained through the video. An energy meter is read and data sent to Boodskap IoT platform through MQTT. {% embed url="" %} # Statstream [Statstream](https://www.statstream.ai/home) in Indian IoT platform, fully developed in India. Statstream is a measurement platform to connect apps, systems and devices, gather insights, optimize operations. YuDash is IIoT gateway partner of Statstream. We are most suitable combination for a flexible, cost effective IoT solutions for energy monitoring, machine monitoring and Industry 4.0 solution. ## YuDash LYNX To Statstream IoT platform The integration of YuDash LYNX with Statatrem IoT platform is explained through the video. An energy meter is read and data sent to Statstream IoT platform through MQTT. {% embed url="" %} [Statstream Documentation link](https://docs.statstream.ai/en/introduction/) # Qubitro [Qubitro](https://www.qubitro.com/) is a Device Data Platform (DDP) built for a hyper-connected world, emerging as the Infrastructure of the Internet of Things. Qubitro allows startups to build and scale more easily, enterprises to accelerate their digital transformation and solution providers to build and sell faster. As part of Qubitro ecosystem, YuDash contributes to innovative IoT edge devices (gateways and dataloggers) for complete IoT solutions for ESG, Energy monitoring, Smart cities and Smart machines. ## YuDash LYNX To Qubitro Device Data platform The integration of YuDash LYNX with Qubitro Device Data platform is explained through the video. An energy meter is read and data sent to Qubitro through MQTT. Please refer to [Qubitro MQTT documentation](https://docs.qubitro.com/platform/mqtt) for more details. {% embed url="" %} PDF guide of above video {% file src="/files/xxG9JaF0jdE7BBv4ta0P" %} # Thingsboard [Thingsboard ](https://thingsboard.io/)is a leading open-source IoT platform for data collection, processing, visualization, and device management. YuDash IoT gateways are seamlessly integrated into Thingsboard cloud and on-premise deployments. YuDash is proud hardware partner of esteemed platform. ## YuDash LYNX To Thingsboard IoT platform The integration of YuDash LYNX with Thingsboard IoT platform is explained through the video. An energy meter is read and data sent to Thingsboard cloud through MQTT. Please refer to [Thingsboard MQTT documentation](https://thingsboard.io/docs/paas/reference/mqtt-api/) for more details. {% embed url="" %} PDF guide of above video {% file src="/files/HGxnfZarD7BfMcILWiBo" %} JSON configuration file {% file src="/files/qHS8l50Per4tz0kxQZQH" %} # Industrial Instruments This section covers integration of YuDash IoT devices with various industrial instruments. These guides refer to practical deployment of the following part of YuDash IIoT Stack:

The integration guides are categorized by application types as below {% tabs %} {% tab title="Energy Meters" %} [Schneider Electric EM6400NG+](/integration-guides/industrial-instruments/energy/se-em6400ng+) [Selec MFM376](/integration-guides/industrial-instruments/energy/selec-mfm376) {% endtab %} {% tab title="Process Control" %} {% endtab %} {% endtabs %} {% hint style="info" %} RS485/Modbus is a popular industrial protocol to enable communication between YuDash IoT Gateway and Industrial Instrument (eg. Energy meter). YuDash IoT Gateway is **Modbus Master** and instrument is **Modbus Slave.** {% endhint %} --- [Next Page](/llms-full.txt/1)