Óêðà¿íñüêà?
Ðóññêàÿ?

---

Needs to translation

User protocol based library

Name:	UserPrtDevs
Founded:	January 2010
Version:	1.7.0
State:	Free (GPL)
Author:	Roman Savochenko
Description:	Library of functions for provide access to data of different network devices with most simply protocols like to wide resources counters.
Address:	DB in file: SQLite.LibDB.tmplib_DevLib and SQLite.LibDB.UserProtocol_uPrt (oscadalibs.db.gz)
Compatibility:	OpenSCADA >= 0.9

About the library

The templates library "DevLib" is created to provide common templates and related functions for custom access to wide range of devices' data with simple protocol to implement into User Protocol module, present complex protocols (ModBus, OPC_UA, HTTP) or direct at internal language and also for some integration the devices data.

The template's names and it's parameters are available in languages: English, Ukrainian and Russian. Source code wrote into language independent mode with calls for the translations by function tr() and the message's translation also allowed for English, Ukrainian and Russian.

To connect the library to the project of the OpenSCADA station it is possible by downloading the attached file of the database, placing it in in the database directory of the station's project and creating the database object for the DB module "SQLite", indicating the database file in the configuration.

To use the templates at generic you need create the device representing object into module of Logical controller and select proper template from the templates library. Next follow to specific for the template into individual description to correct configuration.

In general the custom accessing conception to the device's data we can imagine like to figure 1.

Fig.1. Custom accessing to device's data conception.

As you can see from image 1 intermediate to the device carried out through some transport by the device physical base. Requests to the transport you can send:

• Directly by OpenSCADA system API function of the transport object string messIO( string mess, real timeOut = 0 );, if the protocol specific part very simple and you need only the data extract.
• Wrapped data request req by function int messIO( XMLNodeObj req, string prt ); and for protocol prt, if the protocol part complex enough and already present into OpenSCADA.
• Specific for custom wrapped data request by function int messIO( XMLNodeObj req, "UserProtocol" ); and user protocol implementation, if the protocol part complex enough and not yet present into OpenSCADA. Here user implement self the protocol specific part into UserProtocol module and the data specific part into the template for module Logical controller or direct into controller's procedure of the internal language module JavaLikeCalc.

For placing here a protocol you need do next and follow to shown demands:

• be the copyright holder or the author of the code and distribute it's under any free license, GPL preferred;
• prepare and store the code into a separated DB file of SQLite or as a text file includes all the function's attributes description and the procedure's source text, which was wrote and formed in some system way;
• write a short description and instruction for connect a device by the protocol in way like to the other ones here;
• write the direct request to placing the protocol here to the forum topic "OpenSCADA development" includes a proving of it's ability to work from any OpenSCADA developer or a short demonstration video.

1. SMS (SMS)

Description: Provides operations with SMS by the GSM-modem connected as a serial device. For now supported only sending SMS messages to a number of remote cell phone or GSM modem. For sending supported: ECHO disable, PIN check and set, send in PDU and Text mode.
Author: Roman Savochenko <rom_as@oscada.org>
Version: 2.1.0

Output user protocol's XML request structure: <{cmd} pin="1111" tel="+380XXXXXXXXX" text="{0|1}" err="1:Error">{SMSText}</cmd>

Using/configuring:

1. Create an output transport type "Serial" and set ID that like "SMS", one transport allowed for more receivers.
2. Set proper address, only for Serial device. The serial port speed, asynchronous data format and timeouts will adjusted by the function.
3. Place some commands requests direct to present or new internal OpenSCADA procedures like: req = SYS.XMLNode("send"); req.setAttr("ProtIt","SMS").setAttr("pin","1111").setAttr("tel","+380XXXXXXXXX").setText("Notify message"); SYS.Transport.Serial.out_SMS.messIO(req, "UserProtocol"); rez = req.attr("err").toInt() ? req.attr("err") : "OK";
4. Result: Into variable rez you will get "OK" if no errors occur and the messages transmitted to the receiver.

2. SMTP (SMTP)

Description: Provides operations with EMail by its send through TCP-Socket or SSL. For now supported: TCP, SSL, AUTH, topic encoding for UTF-8.
Author: Roman Savochenko <rom_as@oscada.org>
Version: 1.1.0

Output user protocol's XML request structure: <send auth="{user}:{pass}" from="{FromAddr}" to="{ToAddr}" topic="{My Topic}" err="1:Error">{MessageText}</send>

Using/configuring:

1. Create an output transport type "Sockets" or "SSL" and set ID that like "SMTP", one transport allowed for more receivers.
2. Set proper address, for Sockets(25) or SSL(465). The transport's timeouts will adjusted by the function.
3. Place some commands requests direct to present or new internal OpenSCADA procedures like: req = SYS.XMLNode("send"); req.setAttr("ProtIt","SMTP").setAttr("from","noreply@oscada.org").setAttr("to","oscada@oscada.org").setAttr("topic","My topic").setText("My message"); SYS.Transport.Sockets.out_SMTP.messIO(req, "UserProtocol"); rez = req.attr("err").toInt() ? req.attr("err") : "OK";
4. Result: Into variable rez you will get "OK" if no errors occur and the messages transmitted to the receiver.

3. UPS (UPS)

Description: Uninterruptible power supply unifying data for provide all the data into single attribute of object type "All items" for next the control as the object with the data provide as table, alarming and allowing set writable attributes. The template aimed for using with module "System" data source as "UPS" and widget "Main.objProps" as the data presenter. The template also you can use as example for create like other data unification as complex object with properties, alarming and writing.
Author: Roman Savochenko <rom_as@oscada.org>

Template parameters:

Using/configuring:

1. Create a controller object into module "System" and set ID that like "SYSData".
2. Create a parameter object into previous new the controller object and set ID that like "UPS".
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each the devices. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Source object's address — to address the UPS parameter object like "System.SYSData.UPS".
6. Result: Into attribute items you will get the object with all attributes and its properties. At some violations into attribute "err" you will get the information.
7. Into visual interfaces developing of Vision place widget "Main.objProps" to any page and link it to the parameter object crated into stage 4.
8. Result: Into runtime the page you get table with data of the object, notifications about violations into the header and allowing for set writable properties.

4. Elemer TM510x (TM510x)

Description: Multichannels thermometer Elemer TM5102 and TM5103 of firm Elemer.
Author: Roman Savochenko <rom_as@oscada.org>

Output user protocol's XML request structure: <mess addr="1" err="1:Error">{req}</mess>

Template parameters:

Using/configuring:

1. Create an output transport type "Serial" and set ID that like "tm510", one for each the devices' used serial bus.
2. Set proper the address and the timeouts to the Serial device.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each the devices. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Transport — to ID of the transport into stage 1.
   • Device address — to the device's logical address in bus by upper transport.
6. Result: The logical parameter object will perform interaction and place gathered data to the parameter attributes.

5. EDWARDS TURBOMOLECULAR PUMPS (SCU750)

Description: Typical EDWARDS TURBOMOLECULAR PUMPS (http://edwardsvacuum.com) data request by SCU750 Cotrol Unit protocol.
Author: Roman Savochenko <rom_as@oscada.org>
Sponsored: Vasiliy Grigoriev from "Vacuum technologies laboratory (http://e-beam.ru)".

Output user protocol's XML request structure: <mess addr="1" err="1:Error">{req}</mess>

Template parameters:

Using/configuring:

1. Create an output transport type "Serial" and set ID that like "SCU750", one for each the devices' used serial bus.
2. Set proper the address and the timeouts to the Serial device.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each the devices. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Transport — to ID of the transport into stage 1.
   • Device address — to the device's logical address in bus by upper transport.
   • Period data getting — to need acquisition period which more to real processing by the logical level controller. Commands and some other will process immediate.
6. Result: The logical parameter object will perform interaction and place gathered data to the parameter attributes. Also you allowed for send some commands to the device through writable attributes.

6. Heat counter computer VKT7 (VKT7)

Description: Firm "Teplocom" (http://www.teplocom.spb.ru) computer "VKT-7" for complex heat measurement and the count. The device complex enough by provide more parameters, more history to its and access by nonlinear Serial-based protocol at low speed. The template implement acquisition for all significant parameters, get history by hours, days and result months. Also you can simple enough append for process other left parameters.
Author: Roman Savochenko <rom_as@oscada.org>
Sponsored: Vladislav Chubuk

Output user protocol's XML request structure: <mess addr="1" err="1:Error">{req}</mess>

Template parameters:

Using/configuring:

1. Create an output transport type "Serial" and set ID that like "VKT7", one for each the devices.
2. Set proper the address and the timeouts to the Serial device.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each the devices. Enable the parameter.
5. Create or use a minutes (current) value archivator object (1m, period=60sek.).
6. Create a hours value archivator object (arhH, period=3600sek.), days value archivator object (arhD, 86400sek.) and result month value archivator object (arhM, 86400sek.). Set "Period archiving (sec)" property of the archivators to '0' for disable the data flow from the archive buffer.
7. Into tab "Template configuration" of the logical parameter object you need set:
   • Imitation drift % — to '0' for the imitation disable.
   • Transport — to path of the transport into stage 1, like "Transport.Serial.out_VKT7".
   • Archiver: hours — to the hours archiver into stage 6, like "FSArch.arhH".
   • Archiver: days — to the days archiver into stage 6, like "FSArch.arhD".
   • Archiver: results-month — to the result month archiver into stage 6, like "FSArch.arhM".
   • Archiver: maximum read depth for no hours archiver, days — to need for read no hours archives depth, in days.
8. Into tab "Archiving" set archiving for needs attributes to the archivators.
9. Result: The logical parameter object will perform interaction and place current gathered data to the parameter attributes and current archive. Other archives' data will read parallel from previous set depth by one value for period i.e. one day for minute period for days up to the current and last value.

7. Sycon Multi Drop Protocol (SMDP)

Description: STM devices for resonant frequency measurement for mass of deposited films attached to its surface by Sycon Instruments, Inc. (http://www.sycon.com).
Author: Roman Savochenko <rom_as@oscada.org>
Sponsored: Vasiliy Grigoriev from "Vacuum technologies laboratory (http://e-beam.ru)".

Output user protocol's XML request structure: <mess addr="16" try="1" err="1:Error">{req}</mess>

Template parameters:

Using/configuring:

1. Create an output transport type "Serial" and set ID that like "SMDP", one for each the devices' used serial bus.
2. Set proper the address and the timeouts to the Serial device.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each the devices. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Transport — to ID of the transport into stage 1.
   • Device address — to the device's logical address in bus by upper transport.
   • Period data getting — to need acquisition period which more to real processing by the logical level controller. Commands and some other will process immediate.
6. Result: The logical parameter object will perform interaction and place gathered data to the parameter attributes. Also you allowed for send some commands to the device through writable attributes.

8. Power supply for turbomolecular pumps (TMP-xx03)

Description: Power supply for turbomolecular pumps of firm SHIMADZU, model EI-R04M.
Author: Roman Savochenko <rom_as@oscada.org>
Sponsored: Vasiliy Grigoriev from "Vacuum technologies laboratory (http://e-beam.ru)".

Output user protocol's XML request structure: <mess addr="1" err="1:Error">{req}</mess>

Template parameters:

Using/configuring:

1. Create an output transport type "Serial" and set ID that like "TMP", one for each the devices' used serial bus.
2. Set proper the address and the timeouts to the Serial device.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each the devices. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Transport — to ID of the transport into stage 1.
   • Device address — to the device's logical address in bus by upper transport.
   • Period data getting — to need acquisition period which more to real processing by the logical level controller. Commands and some other will process immediate.
6. Result: The logical parameter object will perform interaction and place gathered data to the parameter attributes. Also you allowed for send some commands to the device through writable attributes.

9. Temperature measurement IT-3 (IT3)

Description: Temperature measurement IT-3 from OmskEtalon.
Author: Roman Savochenko <rom_as@oscada.org>
Sponsored: Vasiliy Grigoriev from "Vacuum technologies laboratory (http://e-beam.ru)".

Output user protocol's XML request structure: <mess addr="1" err="1:Error">{req}</mess>

Template parameters:

Using/configuring:

1. Create an output transport type "Serial" and set ID that like "IT3", one for each the devices' used serial bus.
2. Set proper the address and the timeouts to the Serial device, typical "{serDevPath}:4800:8N2".
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each the devices. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Transport — to ID of the transport into stage 1.
   • Device address — to the device's logical address in bus by upper transport.
6. Result: The logical parameter object will perform interaction and place gathered data to the parameter attributes.

10. IVE-452HS-02 (IVE_452HS_02)

Description: Power supply of beam-electrons evaporator of "Plasma Tech" Ltd, from Moskov.
Author: Roman Savochenko <rom_as@oscada.org>
Sponsored: Vasiliy Grigoriev from "Vacuum technologies laboratory (http://e-beam.ru)".

Output user protocol's XML request structure: <mess addr="255" err="1:Error">{req}</mess>

Template parameters:

Using/configuring:

1. Create an output transport type "Serial" direct, or by the Sockets gate and, set address that like "Sockets.out_IVE", one for each the devices' used serial bus.
2. Set proper the address and the timeouts to the Serial device.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each the devices. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Transport — to the address of the transport into stage 1. Supported tracing for the hot change.
   • Device address — to the device's logical address in bus by upper transport. Supported tracing for the hot change and real the device's address changing.
6. Result: The logical parameter object will perform interaction and place gathered data to the parameter attributes. Also you allowed for send some commands to the device through writable attributes.

11. OPTRIS CT/CTL (OPTRIS)

Description: OPTRIS CT/CTL communication interface of "Optris" GmbH, from Berlin.
Author: Roman Savochenko <rom_as@oscada.org>
Sponsored: Vasiliy Grigoriev from "Vacuum technologies laboratory (http://e-beam.ru)".

Output user protocol's XML request structure: <mess addr="1" cs="1" err="1:Error">{req}</mess>

Template parameters:

Using/configuring:

1. Create an output transport type "Serial" direct, or by the Sockets gate and, set address that like "Serial.out_OPTRIS", one for each the devices' used serial bus.
2. Set proper the address and the timeouts to the Serial device.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each the devices. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Transport — to the address of the transport into stage 1. Supported tracing for the hot change.
   • Device address — to the device's logical address in bus by upper transport.
6. Result: The logical parameter object will perform interaction and place gathered data to the parameter attributes. Also you allowed for send some commands to the device through writable attributes.

12. CTR 100, 101 (CTR)

Description: The RS232C Serial Interface permits the communication between the digital Oerlikon Leybold Vacuum CERAVAC, from Köln.
Author: Roman Savochenko <rom_as@oscada.org>
Sponsored: Vasiliy Grigoriev from "Vacuum technologies laboratory (http://e-beam.ru)".

Output user protocol's XML request structure: <mess err="1:Error">{req}</mess>

Template parameters:

Using/configuring:

1. Create an output transport type "Serial" direct, or by the Sockets gate and, set address that like "Serial.out_CTR", one for each the devices' used serial bus.
2. Set proper the address and the timeouts to the Serial device.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each the devices. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Transport — to the address of the transport into stage 1. Supported tracing for the hot change.
6. Result: The logical parameter object will perform interaction and place gathered data to the parameter attributes. Also you allowed for send some commands to the device through writable attributes.

13. IEC-60870 (IEC60870)

Description: IEC 60870 part 5 is one from the IEC 60870 set of standards which defines systems used for telecontrol (supervisory control and data acquisition) in electrical engineering and power system automation applications. Part 5 provides a communication profile for sending basic telecontrol messages between two systems, which uses permanent directly connected data circuits between the systems. The template implements part 104 (Ethernet transport) for the client and followed services: STARTDT, STOPDT, TESTFR, Ack, C_IC_NA_1, C_CI_NA_1, C_SC_NA_1, M_SP_NA_1, M_ME_NB_1, C_CS_NA_1. To accumulation of the gathered and controlling data used an object into attribute "items" for next the control as the object with the data represent as table, alarming and allowing set the writable attributes. To the data control by attributes at once you can point its into the attribute "itemsSet". Into the template for the first time used the non request mode of an output transport and free attributes creation wile performing.
Version: 1.0.0
Author: Roman Savochenko <rom_as@oscada.org>
Sponsored: Ustijancev Michael.
Implementing task: http://oscada.org/en/development/tasks/posts/subsystem_daq/iec_60870_5_acquisition_protocol_implementation

Template parameters:

Using/configuring:

1. Create an output transport type "Sockets", set address to that like "Sockets.out_IEC60870", one for each the device-PLC.
2. Set proper address and timeouts to the Sockets device-PLC.
3. Create and start a logical controller object or use any present with need scheduling properties. For interaction by IEC-60870-104 you need set the execution period to no lesser then 100ms.
4. Create a logical parameter object and select the template for that, one for each the devices-PLCs. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Transport — to the address of the transport into stage 1. Supported tracing for the hot change.
   • Address — data address in format "{addr}.{OA}".
   • Retry connection time — retry connection time in seconds at the connection lack.
   • Acknowledge lack timeout, in seconds.
   • Acknowledge timeout, in seconds.
   • Test timeout, in seconds.
   • Maximum unconfirmed — not used into the client but it is not generate like flow.
   • Maximum no ack — maximum input packages after what the client will send "Ack".
6. Result: The logical parameter object will perform interaction and place gathered data to the object "items", create/place and check to commands for proper attributes, created by the "itemsSet" instruction.

14. DCON (DCON)

Description: Mostly aimed for example implement the user protocols into OpenSCADA and contains only main functions into the protocol part.
Author: Roman Savochenko <rom_as@oscada.org>

Input user protocol's part: Test implements only processing for requests '#' and '@' with fixed reply data.
Using/configuring:

1. Create an input transport type mostly "Serial" and set any ID.
2. Set proper the address and the timeouts to the Serial device.
3. Set transport protocol to "UserProtocol.DCON".
4. Result: all requests to the input transports will process by input part of the module.

Output user protocol's XML request structure: <ReqSymb addr="1" err="1:Error">{req}</ReqSymb>

Using/configuring:

1. Create an output transport type "Serial" and set ID that like "DCON", one for each the devices' used serial bus.
2. Set proper the address and the timeouts to the Serial device.
3. Place some commands requests direct to present or new internal OpenSCADA procedures like: req = SYS.XMLNode("#"); req.setAttr("ProtIt","DCON").setAttr("addr","1"); SYS.Transport.Serial.out_DCON.messIO(req, "UserProtocol"); data = req.attr("err").length ? "" : req.text();
4. Result: Into variable data you will get the request's data part if no errors occur. The data is analog inputs' values.

15. OWEN (OWEN)

Description: Mostly models of OWEN devices by specific protocol.
Author: Constantine (IrmIngeneer)
Refactoring: Roman Savochenko <rom_as@oscada.org>

Output user protocol's XML request structure: <mess addr="1" err="1:Error">{req}</mess> — message tag

Using/configuring:

1. Create an output transport type "Serial" and set ID that like "OWEN", one for each the devices' used serial bus.
2. Set proper the address and the timeouts to the Serial device.
3. Place some commands requests direct to present or new internal OpenSCADA procedures like: req = SYS.XMLNode("mess"); req.setAttr("ProtIt","OWEN").setAttr("addr","1024").setText(SYS.strFromCharCode(0x87,0x84)); //0xB8,0xDF ? SYS.Transport.Serial.out_SMS.messIO(req, "UserProtocol"); if(!req.attr("err").length) { data = req.text(); //Specific results process }
4. Result: Into variable data you will get the request's data part if no errors occur.

16. One Wire by {DS9097,DS9097U} (1W_{DS9097,DS9097})

Description: One Wire sensors bus implementing by 1Wire-adapter {DS9097,DS9097U}. Supported direct and parasite powering for the temperature sensors.
Supported 1Wire-devices: DS1820, DS1820/DS18S20/DS1920 (not tested), DS1822 (not tested), DS2413, DS2408, DS2450, DS2438.
Author: Roman Savochenko <rom_as@oscada.org>
Version: 1.1.0, 1.1.0

Template parameters:

Using/configuring:

1. Create an output transport type "Serial", set address to that like "oneWire", one for each the One Wire bus.
2. Set proper address, only for the adapter's serial device like "/dev/ttyS{N}". The serial port speed, asynchronous data format and timeouts will adjusted by the template.
3. Create and start a logical controller object or use any present with the need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each One Wire bus. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • Transport of the One Wire bus, Serial — to the address of the transport into stage 1. Supported tracing for the hot change.
   • Rescan period, s — periodicity of rescan to new and removed devices search.
6. Result: The logical parameter object will perform at first searching to 1Wire devices on the bus and create included parameters to the each found one. Next the logical parameter object will perform gather data of the found devices and trace to modify of the writable device's properties.

17. I2C: PCF8591 (PCF8591)

Description: I2C 8-bit 4xA/D and D/A converter. Connect through a Serial output transport into the I2C mode.
Author: Roman Savochenko <rom_as@oscada.org>
Version: 1.0.1

Template parameters:

Using/configuring:

1. Create an output transport type "Serial", set address to that like "i2c", one for each the I2C bus.
2. Set proper address, only the I2C bus address like "/dev/i2c-{N}". Set the symbol's time into the timeouts field to minimum value.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each I2C slave device. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • transport — to the address of the transport into stage 1. Supported tracing for the hot change.
   • addr — the I2C slave device's address [0...119].
   • vRef — reference voltage of the AIs and AO.
6. Result: The logical parameter object will perform interaction and place gathered data to the AI attributes and also will take the AO and write to the chip.

18. I2C: PCF8574 (PCF8574)

Description: I2C 8-bit 8DIO. Connect through a Serial output transport into the I2C mode.
Author: Roman Savochenko <rom_as@oscada.org>
Version: 1.0.0

Template parameters:

Using/configuring:

1. Create an output transport type "Serial", set address to that like "i2c", one for each the I2C bus.
2. Set proper address, only the I2C bus address like "/dev/i2c-{N}". Set the symbol's time into the timeouts field to minimum value.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each I2C slave device. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • transport — to the address of the transport into stage 1. Supported tracing for the hot change.
   • addr — the I2C slave device's address [0...119].
6. Result: The logical parameter object will perform interaction and place gathered data to the DI attributes and also will take the DO and write to the chip.

19. I2C: BMP180 (BMP180)

Description: I2C Pressure and Temperature sensor. Connect through a Serial output transport into the I2C mode.
Author: Roman Savochenko <rom_as@oscada.org>
Version: 1.0.0

Template parameters:

Using/configuring:

1. Create an output transport type "Serial", set address to that like "i2c", one for each the I2C bus.
2. Set proper address, only the I2C bus address like "/dev/i2c-{N}". Set the symbol's time into the timeouts field to minimum value.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each I2C slave device. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • transport — to the address of the transport into stage 1. Supported tracing for the hot change.
   • addr — the I2C slave device's address [0...119].
   • oss — oversampling setting of pressure measurement [0...3].
6. Result: The logical parameter object will perform interaction and place gathered data to the Pressure and Temperature attributes.

20. I2C: DS3231 (DS3231)

Description: I2C RTC chip with Temperature sensor and calibration on it. Connect through a Serial output transport into the I2C mode.
Author: Roman Savochenko <rom_as@oscada.org>
Version: 1.0.0

Template parameters:

Using/configuring:

1. Create an output transport type "Serial", set address to that like "i2c", one for each the I2C bus.
2. Set proper address, only the I2C bus address like "/dev/i2c-{N}". Set the symbol's time into the timeouts field to minimum value.
3. Create and start a logical controller object or use any present with need scheduling properties.
4. Create a logical parameter object and select the template for that, one for each I2C slave device. Enable the parameter.
5. Into tab "Template configuration" of the logical parameter object you need set:
   • transport — to the address of the transport into stage 1. Supported tracing for the hot change.
   • addr — the I2C slave device's address [0...119].
6. Result: The logical parameter object will perform interaction and place gathered data to the DateTime, Temperature and some one state attributes and also will take the DateTime, some one state attributes and write it to the chip.

21. I2C: AT24C{32|64} (AT24CXX)

Description: Provides operations with EEPROM memory based on I2C chips AT24C32 (4KB) and AT24C64 (8KB). Supported random reading and writing.
Author: Roman Savochenko <rom_as@oscada.org>
Version: 1.0.0

Output user protocol's XML request structure: <{cmd} addr="{ChipAddr}" off="{MemOffset}" size="{ReadSize}" err="1:Error">{ReadWriteSeq}</{cmd}>

Using/configuring:

1. Create an output transport type "Serial", set address to that like "i2c", one for each the I2C bus.
2. Set proper address, only the I2C bus address like "/dev/i2c-{N}". Set the symbol's time into the timeouts field to minimum value.
3. Place some commands requests direct to present or new internal OpenSCADA procedures like: req = SYS.XMLNode("read"); req.setAttr("ProtIt","AT24CXX").setAttr("addr",87).setAttr("off",1000).setAttr("size",20).setText("My message"); req = SYS.XMLNode("write"); req.setAttr("ProtIt","AT24CXX").setAttr("addr",87).setAttr("off",1000).setText("Stored data");
4. Result: Into text() for "read" you will get the read data if no errors occur.

22. GPIO: DHT11,22 (AM23XX) (DHT)

Description: Digital Temperature and Humidity Sensor for models: DHT11, DHT12, AM2302, AM2320, ... . The module designed for the sensors connect through GPIO, mostly it's Raspberry PI BCM2835 GPIO.
Conditions: Exclusively realtime planing in the priority 199 (FIFO-99).
Author: Roman Savochenko <rom_as@oscada.org>
Version: 1.0.0

Template parameters:

Using/configuring:

1. Create an output controller and parameter object in DAQ module "BCM 2835", by default it's "pi.pi".
2. Create and start a logical controller object or use any present with need scheduling properties (FIFO-199).
3. Create a logical parameter object and select the template for that, one for each sensor. Enable the parameter.
4. Into tab "Template configuration" of the logical parameter object you need set:
   • addr — To the address of the "BCM 2835" parameter like "DAQ.BCM2835.pi.pi". Supported tracing for the hot change.
   • pin — GPIO pin number where connected the data pin of the sensor.
   • tries — Tries of the sensor read.
   • dev — Generic device specific selection.
5. Result: The logical parameter object will perform interaction and place gathered data to the Temperature and Humidity attributes.

23. GPIO|I2C: 1602A(HD44780) (1602A)

Description: LCD Module 1602A, STN, BLUB, 16 Character x 2 Line, 5 x 8 Dots, by the direct (Raspberry PI BCM2835 GPIO) or I2C (PCF8574) wiring.
Conditions: Default planing policy but realtime one preferred.
Author: Roman Savochenko <rom_as@oscada.org>
Version: 1.1.0

Template parameters:

Using/configuring:

1. Create an output controller and object of parameter in DAQ module "BCM 2835", by default it's "pi.pi" or create an output transport type "Serial", set address to that like "i2c", one for each the I2C bus.
2. Create and start a logical controller object or use any present with need scheduling properties.
3. Create a logical parameter object and select the template for that, one for each display. Enable the parameter.
4. Into tab "Template configuration" of the logical parameter object you need set:
   • transport — To the address of the "BCM 2835" parameter like "DAQ.BCM2835.pi.pi" or to the address of the transport into stage 1. Supported tracing for the hot change.
   • addr — The I2C slave device's address [0...119].
   • RS, E, D4, D5, D6, D7 — GPIO pins number where connected proper data ones of the sensor.
5. Result: The logical parameter object will perform interaction and set lines' values to the display.