Tunnel – DNS Parameter configuration: “DNS_”

Looking for something else?

In the previous section about DynDNS we explained how and why we use it when we have a few remote modem SIMs that have dynamic IP addresses. If you plan to use and control a large number of devices, this is not practical. Also, DynDNS requires you to have an external server, which means that any possible drops on the server are harder to control.

The following parameters are useful for when you are required to use your own server to collect the changes detected by MTX-Tunnel in the IP addresses.

In other words, these parameters will make sure MTX-Tunnel informs your server of any changes in its IP address, giving you complete control of the system at all times.

DNS_enabled

Description: enable the DNS service using your own server. Every time the modem starts a data connection or changes the IP address, it is sent to your configured server.

Possible values:

  • on, off
  • Default value: off

Additional notes:

  • Only use the DNS feature when your SIM is dynamic IP provisioned. It makes no sense to use a dynamic IP provisioned SIM if your network operator has fixed IP addressing
  • DNS must be used in incoming connection requests with MTX-Tunnel services using socket servers like:
    • GPRS-Serial RS232 server mode tunnel
    • WebServer
    • Telnet
    • If you are going to use MTX-Tunnel client connection services, meaning that the MTXTunnel starts with a connection from a well known IP address, the DNS service is not needed and must be disabled (value “off”)

DNS_mode

Description: The MTXTunnel mode, in which MTX-Tunnel sends the change in IP address to a server. We can use a TCP socket or HTTP protocol for web server.

Possible values:

  • socket, socketjson, http, mqtt
  • Default value: socket

Additional notes:

  • If you are going to write your own code/application, use the “socket” option
  • If you already have a web server and the code is written in ASP or PHP, we recommend that you use the “http” option
  • If you are going to send data from sensors to a MQTT broker, it will be easier to use the “mqtt” method. From the MTX-Tunnel 9.25 on it is possible to configure the “mqtt” mode. If you select this method don’t forget to configure the MQTT parameters and the DNS_mqttTopic parameter

DNS_password

Description: You can secure this service by setting up a password. MTX-Tunnel will send the DNS_password in any new GPRS connection or if there are any IP address changes and your server will have to check the password.

Possible values:

  • A text string of up to 64 characters
  • Default value: none

Additional notes:

  • DNS_password is sent using either “socket” or “http” transmission mode

DNS_server

Description:

  • Socket mode: (DNS_mode: socket) The value is the DNS or IP server address where the new IP address is to be sent..
  • HTTP mode: (DNS_mode: http) The value is the URL (domain + web page) of the WebServer to which you will pass on information about the new IP address.

Possible values:

  • Text string of less than 255 characters
  • Default value: none

Additional notes:

  • In HTTP mode “DNS_mode: http”, DNS_server URL does not include “http://” string. DNS example URL: www.mtxtunnel.com/dns.asp
  • In Socket mode, MTX-Tunnel sends the following string to the server:
#IMEI#DNS_password#IPPublica#
  • In HTTP mode, MTX-Tunnel sends the following string to server:
URL?IMEI=<suIMEI>&PASS=<DNS_password>&IP=<IP Public>
  • If you program web pages in ASP, you can collect the information using this method as an example:
<%
IMEI=Request.QueryString(“IMEI”)
Password=Request.QueryString(“PASS”)
IP=Request.QueryString(“IP”)
%>

DNS_port

Description: TCP DNS server port being used in DNS socket mode (DNS_mode: socket).

Possible values:

  • 1… 65535
  • Default value: 20011

Additional notes:

  • Only use this parameter if “socket”mode is used. If you use “http” mode, the standard port is 80. However if you use another one, you need to include it in the DNS_server parameter
  • E.g. if you are going to use port 20011, DNS_server value parameter is: www.mtxtunnel.com:20011/dns.asp

DNS_extended

Description: if enabled, and only if the DNS service is enabled too (DNS_enabled: on), MTX-Tunnel will send the password and IP address information together with the IMEI and more information like the GPIO status. This is useful in telemetry applications. To send additional information, DNS_extended must be configured to “on”.

Possible values:

  • on, off
  • Default value: off

Additional notes:

  • DNS_extended “on”, DNS_mode set as “socket”, the information sent to the server is:
#IMEI#DNS_password#IPPublica#gpio1#gpio2#gpio3#gpio4#gpio5
#gpio6#gpio7#gpio8#gpio9#gpio10#ADC1#ADC2#<gpsLocation>#

The additional extended information is shown.
gpioX is input/output X value (0 -1)
ADCX is analog to digital converter X value.
In the MTX terminal modems with GPS receiver, the GPS location information is also added.

  • DNS_extended “on”, DNS_mode set as “http”, the information sent to the server is:
URL?IMEI=<suIMEI>&PASS=<DNS_password>&IP=<IP Public> &GPIO1=X
&GPIO2=X &GPIO3=X &GPIO4=X &GPIO5=X &GPIO6=X &GPIO7=X &GPIO8=X
&GPIO9=X &GPIO10=X &ADC1=X&ADC2=X&GPS=<gpsLocation>

The additional extended information is shown.
gpioX is input/output X value (0 -1)
ADCX is analog to digital converter X value.
In the MTX terminal modems with GPS receiver, the GPS location information is also added.

DNS_gpios

Description: When this parameter is enabled it can send DNS information (which can include GPIO and ADC values if DNS_extended = “on”) when there is a change in a digital input.

Possible values:

  • on, off
  • Default value: off

Additional notes:

  • MTX-Tunnel sends just one data DNS information string if there has been one or several changes in digital inputs
  • Parameter available from version MTX-Tunnel v5.3

DNS_adc1, DNS_adc2

Description: This parameter, if enabled, can send DNS information (which can include GPIO and ADC values if DNS_extended = “on”) only when the analog input is above or below trigger value.

Possible values:

  • Possible values: 0, 250 … 47750
  • Default value: 0

Additional notes:

  • 0 value disables this feature and a DNS string will be not sent
  • DNS_adcX >=250 sets the trigger analog value above or below +-250mV, if it exceeds this value a DNS frame string will be sent
  • DNS_adc1: 1200 means that when DNS_adc1 > 1200mV + 250mV, the DNS text string will be sent, as well as when DNS_adc2 < 1200mV – 250mV
  • Parameter available from MTX-Tunnel v5.3

DNS_period

Description: A data string with the DNS information is sent whenever the MTX-Tunnel IP address changes, but you can also define it to send the IP address periodically. This is useful for a more secure indication of IP address changes and it establishes timing periods by sending telemetric data if the DNS_extended parameter is enabled (value “on”).

  • 0, 30… 2592000
  • Default value: 0

Additional notes:

  • Value=0 means DNS information is not sent periodically
  • Value of time is in seconds

DNS_httpMode

Description: This parameter allows you to choose the type of communication that will be used when DNS_mode is set to “http” mode. You can choose between “get” and “json”

Possible values:

  • get, getjson, postjson
  • Default value: get

Additional notes:

  • The parameter is available from MTX-Tunnel version 8.10 onwards. Before this version the only possible option was “get”. It is strongly recommended not to use the option “get”, and
    use the option ‘’getjson” or “postjson”.
  • EXAMPLE of data transmission in “get” mode where DNS_extended parameter has the value “off”:
    http://www.mydomain.com?TYPE=DNS&IMEI=357973041110401&PASS=ID000001&IP=95.126.113.202&CSQ=24&VER=9.12&AUX=0&MOD=201
  • EXAMPLE of data transmission in “getjson” mode where DNS_extended parameter has the value “off”:
    {“TYPE”,”DNS”,”IMEI”: 357973041110401,“P”:”ID001”,”IP”:”95.126.113.202”, ”CSQ”:24,”VER”:”9.12”, “AUX”:”0”,”MOD”:201}
    Where:
    TYPE: DNS frame type
    IMEI: IMEI of the modem (unique device identification)
    P: user’s field in DNS_password parameter
    IP: MTX-Tunnel IP
    CSQ: GSM coverage of MTX (0… 31)
    VER: MTX-Tunnel firmware version
    AUX: Reserved for configuration version control
    MOD: MTX terminal model
  • EXAMPLE of data transmission in “getjson” mode where DNS_extended parameter has the value “on”:
    {“TYPE”,”DNS”,”IMEI”: 357973041110401, “P”:”ID001”,”IP”:”95.126.113.202”, ”CSQ”:24,”VER”:”9.12”, “AUX”:”0”,”MOD”:201,”IO1”:0,”IO2”:0,”IO3”:0,”IO4”:0,”IO5”:0, ”IO6”:0,“IO7”:0,”IO8”:0,”IO9”:0,”IO10”:0,”AD1”:100,”AD2”:2000,”CO1”:”0”,”CO2”:”0”, ”CID”:”214;07;0322;4E8F”}”}
    Where:
    TYPE: DNS frame type
    IMEI: IMEI of the modem (unique device identification)
    P: user’s field in DNS_password parameter
    IP: MTX-Tunnel IP
    CSQ: GSM coverage of MTX (0 … 31)
    VER: MTX-Tunnel firmware version
    AUX: Reserved for configuration version control
    MOD: MTX terminal model
    IO1: Value of digital input/output 1 of the modem (if it is available)
    IO2: Value of digital input/output 2 of the modem (if it is available)
    IO3: Value of digital input/output 3 of the modem (if it is available)
    IO4: Value of digital input/output 4 of the modem (if it is available)
    IO5: Value of digital input/output 5 of the modem (if it is available)
    IO6: Value of digital input/output 6 of the modem (if it is available)
    IO7: Value of digital input/output 7 of the modem (if it is available)
    IO8: Value of digital input/output 8 of the modem (if it is available)
    IO9: Value of digital input/output 9 of the modem (if it is available)
    IO10: Value of digital input/output 10 of the modem (if it is available)
    AD1: Value of analog input 1 of the modem (if it is available)
    AD2: Value of analog input 2 of the modem (if it is available)
    CO1: Value of pulse counter input 1 (if it is available)
    CO2: Value of pulse counter input 2 (if it is available)
    CID: GSM cell information (for GSM localization)
  • EXAMPLE of data transfer in “postjson” mode where DNS_extended parameter has the value “off”. When using “postjson” mode data is sent to JSON as follows:
    {“IMEI”:”357042060366409”,”TYPE”:”DNS”,“P”:”ID-12345678”, ”IP”:”95.126.113.202”,”CSQ”:24,”VER”:”9.12”,“AUX”:”4”,”MOD”:”201”,VCC:12100}
    Where:
    TYPE: DNS frame type
    IMEI: MTX internal indentification
    P: user’s field in DNS_password parameter
    IP: MTX-Tunnel IP
    CSQ: GSM coverage of MTX (0 … 31)
    VER: MTX-Tunnel firmware version
    AUX: Reserved for configuration version control
    MOD: MTX terminal model
    VCC: MTX supply voltage (in millivolts)
  • EXAMPLE of data transmission in “postjson” mode where DNS_extended parameter has the value “on”. When using “postjson” mode data is sent to JSON as follows:
    {“IMEI”:”357042060366409”,”TYPE”:”DNS”,“P”:”ID-12345678”, ”IP”:”95.126.113.202”,”CSQ”:24,”VER”:”9.12”,“AUX”:”4”,”MOD”:”201”,VCC:12100,”IO1”:0,”IO2”:0, ”IO3”:0,”IO4”:0,”IO5”:0,”IO6”:0,”IO7”:0,“IO8”:0,”IO9”:0,”IO10”:0,”AD1”:0,”AD2”:0, ”CO1”:”0”,”CO2”:”0”,”CID”:”214;07;0322;4E8F”}
    Where:
    TYPE: DNS frame type
    IMEI: MTX internal indentification
    P: user’s field in DNS_password parameter
    IP: MTX-Tunnel IP
    CSQ: GSM coverage of MTX (0 … 31)
    VER: MTX-Tunnel firmware version
    AUX: Reserved for configuration version control
    MOD: MTX terminal model
    VCC: MTX supply voltage (in millivolts)
    IO1: Value of digital input/output 1 of the modem (if it is available)
    IO2: Value of digital input/output 2 of the modem (if it is available)
    IO3: Value of digital input/output 3 of the modem (if it is available)
    IO4: Value of digital input/output 4 of the modem (if it is available)
    IO5: Value of digital input/output 5 of the modem (if it is available)
    IO6: Value of digital input/output 6 of the modem (if it is available)
    IO7: Value of digital input/output 7 of the modem (if it is available)
    IO8: Value of digital input/output 8 of the modem (if it is available)
    IO9: Value of digital input/output 9 of the modem (if it is available)
    IO10: Value of digital input/output 10 of the modem (if it is available)
    AD1: Value of analog input 1 of the modem (if it is available)
    AD2: Value of analog input 2 of the modem (if it is available)
    CO1: Value of pulse counter input 1 (if it is available)
    CO2: Value of pulse counter input 2 (if it is available)
    CID: GSM cell information (for GSM localization)

DNS_serverLogin

Description: This parameter allows you to establish a login (username) that must be used by MTX-Tunnel to send data to a Web server containing a Login/Password authentication system.

Possible values:

  • Text string of up to 64 characters
  • Default value: none

Additional notes:

  • If your web server does not use a simple authentication system consisting of a Login and Password, this parameter is not necessary. It is necessary, however, in those web servers that
    use authentication systems.
  • This parameter is available in versions of MTX-Tunnel from v8.10.

DNS_serverPassword

Description: This parameter allows you to establish a password that must be used by MTX-Tunnel to send data to a Web server containing a Login/Password authentication system.

Possible values:

  • Text string of up to 64 characters
  • Default value: none

Additional notes:

  • If your web server does not use a simple authentication system consisting of a Login and Password, this parameter is not necessary. It is necessary, however, in those web servers that use authentication systems.

DNS_https

Description: Allows to state whether information is sent via http or via https in encrypted format.

Possible values:

  • on, off
  • Default value: off

Additional notes:

  • Keep in mind that if you want to activate this option, you will need a web server with SSL support

DNS_header1, DNS_header2, DNS_header3

Description: Allows to use personalized HTTP headers.Very useful for communication between MTX-Tunnel and thirdparty web platforms (like THINGWORKS).

Possible values:

  • ASCII string up to 64 charaters
  • Default value: none

Additional notes:

  • The headers have the following format: nameHeader;valueHeader . That is to say, fields are separated by ; (semicolon)
  • You will find them necessary if you want your MTX-Tunnel to communicate with some generic platforms. For example, to communicate with Thingworks platform you will have to specify something similar to:
    DNS_header1: Content-Type;application/json
    DNS _header2: Accept;application/json
    DNS _header3: appKey;194f5476-7346-4638-ac30-bbca28595be1

DNS_mqttTopic

Description: Configure the topic that MTX-Tunnel will use to publish all data in the DNS_ service.

Possible values:

  • ASCII string up to 64 charaters
  • Default value: none

Additional notes:

  • In the same way as the MQTT_attopicX parameters, you can use the [IMEI] tag in the parameter and the MTX-Tunnel will internally replace that tag with the appropriate value. For example, if your modem has the IMEI 354740050182909 you could specify in the config.txt configuration file the value:
    DNS_mqttTopic: [IMEI]/DNS
    And the MTX-Tunnel would send the DNS service data using the topic:
    354740050182909/DNS
  • Data are sent to the MQTT topic in JSON format. Check the parameter DNS_httpMode to find information about sent JSON

Do you have a question? Need a quote? Please contact us.

Appendices and other documents

Appendices and other documents

Appendices and other documents

FAQ

Please check these items in this order:
  • the battery level: if the battery level is too low or empty, the product will not run properly or not run at all.
  • Modem reception level: a bad signal at the modem may also prevent the hub from uploading files. Look to move the product or install an external antenna to improve signal quality.
  • The last configuration file: a bad configuration file can block the product.

Remotely, by checking the regularly uploaded files if the product configuration is correct.

On site, by passing the magnet over the product, you will hear 3 short beeps.

Replace the product and inject the configuration from the old product into the new one. If a white list is used, remember to inject it into the new product as well.
No, the concentrator is not able to decrypt data from WM-BUS equipment because it does not have a safe on board to guarantee the security of the encryption keys of your equipment. The recovered data is deposited without modification (without decryption) by the concentrator on your remote server.

Appendix and other documents

FAQ

CONFIGURATION OF THE WEBDYNRF GATEWAY

  • If the file is deleted from the directory after connecting the WebdynRF gateway, the problem is usually due to a file format error. The configuration and control files must follow the format described in the schema (XSD) files. To check schema consistency, open the XML file with the Notepad++ text editor and install the “XML Tool” add-on. Next, copy the corresponding XSD file to the XML file in the same directory, and select “Validate now” in XML Tool. Errors detected by the tool should be displayed.
  • If the file is not deleted from the server, the most common problem is that the file has not been located correctly. The file must be available on the server in the “INBOX” directory and in the sub-directory bearing the product UID name (e.g.: “/INBOX/0045CE/”).

GENERAL USE OF THE WEBDYNRF GATEWAY

The amount of data exchanged on the GPRS network varies depending on the configuration. However, the average consumption would be about 5MB / month.
The WebdynRF gateway consumes an average of about 250mA.

There are 2 firmware updating methods:
Local updating:
On the WebdynRF configuration interface, go to the “Actions” tab and select the updater in the “File upload” menu before clicking on the “Upload” button

Remote updating:
Upload the file containing the updater (file with extension “.bz2”) in the “BIN” directory to the FTP server . Next, place the update command in the INBOX directory corresponding to your gateway (“INBOX/”, with, the identifier of the gateway concerned)

The update command must follow the following format:

      updater.tar.bz2
      checksum_md5

updater.tar.bz2
checksum_md5

With:

  • updater.tar.bz2: Updater file name uploaded to the “BIN” directory
  • checksum_md5: Md5 code of the updater file

A lack of connection to the FTP server may be due to a network connection problem (Ethernet or GPRS), an FTP login problem or a failure to initiate the connection.

If you cannot connect to the network, check the following points:

  • Ethernet:
    • Modem set to “off” or “always off”
    • “Gateway” fields correctly entered
    • At least one DNS server must be configured
  • GPRS:
    • Modem set to “on”
    • APN, APN ID and APN password correctly entered
    • GPRS call number set to “*99***1#”

If you cannot log in, check the following points:

  • Incorrect FTP parameters
  • TCP port 21 closed at output
  • Domain name resolution problem: the DNS server is not specified

If the connection fails to initiate:

In this case, only the automatic connection does not work. The problem is probably caused by an incorrect schedule configuration. Please note, the schedule ID must be an integer.

 PARTICULAR APPLICATION OF THE WEBDYNRF WIRELESS M-BUS GATEWAY

For the WM-bus module data to be transmitted, you must:

  • Choose the mode corresponding to the modules used (S, T or N)
  • Define the modules or groups of modules to be processed

A module may be defined in a unique way by all the fields below:

  • Id
  • Manufacturer
  • Version
  • Medium

If a module’s data is encrypted, the encryption key for this module can be defined in the “Key” field.

To simplify the entry of the modules to be processed, a module group can be defined that conforms to the fields entered. The other fields will then be left empty (below is an example of a configuration for retrieving all Webdyn manufacturer (WDN) modules with the encryption key “00000000000000000000000000000000”.

  •   Id :
  •   Manufacturer : WDN
  •   Medium :
  •   Version :
  •   Label : Webdyn
  •   Key : 00000000000000000000000000000000

Note: In order for the modules (filters) entered to be taken into account, the “ByPass filter” mode must be deactivated.

Click here to read the media file 

Click here to read the units file 

 PARTICULAR APPLICATION OF THE WEBDYNRF WAVENIS

The tool is connected to the gateway via the installer access (install).

It is therefore necessary to use the installer password (default is “middle”), and not the administrator’s password (default is “high”)

The statuses transmitted by the WebdynRF gateway are the raw values contained in the Wavenis modules. They are transmitted without interpretation. For further details, please refer to the Coronis module manuals.

Annexes and other documents

FAQ

CONFIGURATION OF THE WEBDYNRF GATEWAY

  • If the file is deleted from the directory after connecting the WebdynRF gateway, the problem is usually due to a file format error. The configuration and control files must follow the format described in the schema (XSD) files. To check schema consistency, open the XML file with the Notepad++ text editor and install the “XML Tool” add-on. Next, copy the corresponding XSD file to the XML file in the same directory, and select “Validate now” in XML Tool. Errors detected by the tool should be displayed.
  • If the file is not deleted from the server, the most common problem is that the file has not been located correctly. The file must be available on the server in the “INBOX” directory and in the sub-directory bearing the product UID name (e.g.: “/INBOX/0045CE/”).

GENERAL USE OF THE WEBDYNRF GATEWAY

The amount of data exchanged on the GPRS network varies depending on the configuration. However, the average consumption would be about 5MB / month.
The WebdynRF gateway consumes an average of about 250mA.

There are 2 firmware updating methods:
Local updating:
On the WebdynRF configuration interface, go to the “Actions” tab and select the updater in the “File upload” menu before clicking on the “Upload” button

Remote updating:
Upload the file containing the updater (file with extension “.bz2”) in the “BIN” directory to the FTP server . Next, place the update command in the INBOX directory corresponding to your gateway (“INBOX/”, with, the identifier of the gateway concerned)

The update command must follow the following format:

      updater.tar.bz2
      checksum_md5

updater.tar.bz2
checksum_md5

With:

  • updater.tar.bz2: Updater file name uploaded to the “BIN” directory
  • checksum_md5: Md5 code of the updater file

A lack of connection to the FTP server may be due to a network connection problem (Ethernet or GPRS), an FTP login problem or a failure to initiate the connection.

If you cannot connect to the network, check the following points:

  • Ethernet:
    • Modem set to “off” or “always off”
    • “Gateway” fields correctly entered
    • At least one DNS server must be configured
  • GPRS:
    • Modem set to “on”
    • APN, APN ID and APN password correctly entered
    • GPRS call number set to “*99***1#”

If you cannot log in, check the following points:

  • Incorrect FTP parameters
  • TCP port 21 closed at output
  • Domain name resolution problem: the DNS server is not specified

If the connection fails to initiate:

In this case, only the automatic connection does not work. The problem is probably caused by an incorrect schedule configuration. Please note, the schedule ID must be an integer.

 PARTICULAR APPLICATION OF THE WEBDYNRF WIRELESS M-BUS GATEWAY

For the WM-bus module data to be transmitted, you must:

  • Choose the mode corresponding to the modules used (S, T or N)
  • Define the modules or groups of modules to be processed

A module may be defined in a unique way by all the fields below:

  • Id
  • Manufacturer
  • Version
  • Medium

If a module’s data is encrypted, the encryption key for this module can be defined in the “Key” field.

To simplify the entry of the modules to be processed, a module group can be defined that conforms to the fields entered. The other fields will then be left empty (below is an example of a configuration for retrieving all Webdyn manufacturer (WDN) modules with the encryption key “00000000000000000000000000000000”.

  •   Id :
  •   Manufacturer : WDN
  •   Medium :
  •   Version :
  •   Label : Webdyn
  •   Key : 00000000000000000000000000000000

Note: In order for the modules (filters) entered to be taken into account, the “ByPass filter” mode must be deactivated.

Click here to read the media file 

Click here to read the units file 

 PARTICULAR APPLICATION OF THE WEBDYNRF WAVENIS

The tool is connected to the gateway via the installer access (install).

It is therefore necessary to use the installer password (default is “middle”), and not the administrator’s password (default is “high”)

The statuses transmitted by the WebdynRF gateway are the raw values contained in the Wavenis modules. They are transmitted without interpretation. For further details, please refer to the Coronis module manuals.

Appendices and other documents

Other manuals

Application Notes

FAQ

Gateway configuration:

Start by checking that the computer’s IP parameters are compatible with the WebdynSunPM IP address (by default 192.168.1.12)

Launch a web browser (Chrome, Firefox, Edge, Safari, etc.) and enter the WebdynSunPM concentrator IP address in the address bar. An authentication page is displayed:

The default accesses are:

IdentifiantMot de passe
userhighhigh

Click “Login”

There are two configuration solutions, using the web interface and using text messages:
  • Configuration using the web interface:
Start by establishing a connection to the concentrator by connecting to it to access the server configuration: Enter the “ethernet” or “modem” connection type: For an ethernet configuration, make sure the IP parameters are compatible with server access according to the concentrator local network configuration. For an ethernet connection, the configuration must be compatible with the concentrator’s local network topology so that it can access the servers. This configuration is done from the “Networks” configuration page (see section 3.2.2.3: “Networks). For a modem connection, the modem configuration must be correct before a connection can be set up. This configuration is done from the “Modem” configuration page (see section 3.2.2.4: “Modem). The parameters for the servers to be configured are at least the following: Therefore the following fields need to be configured: “Interface”, “Type”, “Server type”, “Address”, “Port”, “Login” and “Password”. The other fields can be left at the default values subject to the directories having been properly created beforehand. See section 3.1.2: “Configuration files for more details.
  • Text message configuration:
Text message configuration requires sending the following commands:
      • Apn: to configure the SIM card APN. (see section 3.2:“apn” modem configuration command)
      • Ftp: to configure the FTP server that will contain the concentration configuration (see section 3.3: “ftp” FTP configuration command”).
      • Connect: to launch the connection to the FTP server and load the configuration (see section 3.1: ““connect” connection command

Access to the FTP server depends on the selected solution.

If you have chosen a portal, it will give you the FTP server access identifiers.

If you want to use your own FTP server, contact your network administrator.

For all other configurations, and to determine the best solution, contact the Webdyn sales department which will advise you and direct you to the relevant contacts: contact@webdyn.com

General gateway use

There are 2 methods to force a concentrator factory reset:
  • Press the Factory Reset button on the concentrator for 20 seconds:
Wait. The concentrator will reboot using its factory configuration.
  • If a SIM card is installed and configured, a “factory” text message can also be used for factory reset. Just send the “factory” text message to the SIM card phone number (see section 3.7: “factory” reset command”)

It is possible to send commands to connected devices if they accept them.

The WebdynSunPM can store up to 50Mb of uncompressed data per declared device.

If there is no access to the remote server, the WebdynSunPM concentrator can store the data for several months.

The maximum data storage time varies depending on the amount of data to be collected and the configured collection frequency.

The average storage time varies from 3 to 4 months.

The average service life of the battery is 5 years.

It may vary depending on the installation environment.

All our products are guaranteed for 2 years.

For more information, read the general terms and conditions of sale.

The data volume depends on the exchanged files.

The average is about 5 MB per month but this varies from one installation to another.

Inverter compatibility

See section 1.4: “Supported devices”.

Modbus device compatibility:

Yes, different Modbus devices can be connected to the same serial port.

Device compatibility:

    • Same type of RS485 or 4 wire connection.
    • All devices should be able to be configured using identical bus specifications. Same speed, same parity, same number of stop bits and data bits on all devices and on the WebdynSunPM.
    • Each device must be assigned a unique Modbus address (between 1 and 247) on the bus. (UnitID)

Annexes and other documents

FAQ

Annexes and other documents

FAQ

Annexes and other documents

FAQ

Appendices and other documents

Appendices and other documents

Appendices and other documents

Appendices and other documents

Appendices and other documents

Appendices and other documents

Appendices and other documents

Appendices and other documents

Appendices and other documents

Appendices and other documents

FAQ

CONFIGURATION OF THE WEBDYNSUN GATEWAY

  • Start by checking that your computer’s IP parameters are compatible with the WebdynSun’s “IP” address (the default is 192.168.1.12). 
  • Next, launch a web browser (Firefox or IE) and enter the WebdynSun’s IP address in the address bar. An authentication page will appear: 

The default accesses are:
Username: userhigh
Password: high

  • Click on “log in”  

There are two types of configuration: via the web interface or via SMS.

Configuration of the web interface:

1/ Go to the configuration page with the gateway IP address (default 192.168.1.12)

2/ Go to the Configuration tab.

3/ Select either the Ethernet or modem connection mode:

If connecting via the local network (Ethernet):

  • Edit the WebdynSun’s IP parameters by assigning it a network-compatible address.

Please note, all fields must be completed in accordance with the configuration of your local network.

If connecting via the GPRS network (Modem):

  • Change the connection settings of the GPRS modem to the settings provided by your mobile operator.

4/ Edit the FTP server parameters.

5/ Confirm the changes.

6/ Restart the WebdynSun gateway using the new settings.

7/ In the menu, click on the “installation” tab, followed by the “connection” sub-tab and start the connection.

Configuration via SMS:

This configuration method requires the use of an active SIM card with a data option and a pin code that must be either “0000” or disabled.
The SIM card must be inserted into the unit before connection to the mains supply.
After connection to the mains supply, send the following SMS messages to the number of the previously inserted SIM card:

SMS for configuring the APN:
After replacing the generic fields with those of your operator, send the following SMS*:
apn=apn_name;usr=user_name;pwd=password;

Replace the above SMS fields with the following information:

  • apn_name: APN name supplied by your mobile operator
  • user_name: APN ID supplied by your mobile operator
  • password: APN password supplied by your mobile operator

SMS for FTP configuration:
After replacing the generic fields with those of your FTP server, send the following SMS*:
Ftp=server_name:user_name:password:port;

Replace the above SMS fields with the following information:

  • server_name: FTP server address
  • user_name: FTP account ID
  • Password: FTP account password
  • Port: FTP server port (the default port is 21)

Connection SMS:

Send the word “connect” by SMS* to launch a connection to the FTP server

*Please note: the formatting of the SMS must be exactly identical to that shown above (e.g.: no spaces between characters, etc.)

There are 2 ways of resetting the gateway.

  • If connecting by Ethernet:
    • Disconnect from the mains
    • Remove the cover
    • Disconnect the battery
    • Put the DIP Switch 2 on the WebdynSun card in “ON” position
    • Start the WebdynSun by connecting it only to the mains power supply
    • Wait until all the LEDs flash and then stop flashing (3 to 5 mins).
    • Disconnect from the mains
    • Reset the Dip Switch 2 to “OFF” 
    • Reconnect the battery
    • Reconnect to the mains supply and the WebdynSun starts normally.
  • If there is a SIM card inserted in the unit:
    • Send an SMS message containing the word “factory” to the number of the inserted SIM card.

NB : Resetting the gateway restores the configuration to its original state. Please note: data will be saved but the specific settings will not. Therefore, all the settings must be reconfigured.

Commands can be sent to connected devices with the exception of certain inverters and Modbus slaves that do not accept write requests.

If the device allows it, command files can be created on the FTP server.

The WebdynSun has a memory of about 100MB.

Therefore, if the remote server cannot be accessed, the WebdynSun gateway can backup data for several months.
The maximum data backup time varies depending on the amount of data to be collected.

The average backup time ranges from 3 to 4 months.

The average battery life is 5 years.

It may vary depending on the installation environment.

Yes, data may be sent to a PLC if the latter is equipped with a Modbus protocol.
The “Report” configuration file allows the WebdynSun gateway to automatically write the values read on a Modbus slave

All our products are guaranteed for 2 years.

For further information, please see our general conditions of sale.

Files uploaded by the WebdynSun gateway are compressed in Gz format.

The data contained in these files is structured in csv format.

The data volume depends on the files exchanged.

The average is about 5 MB per month but this varies from one installation to another.

INVERTER COMPATIBILITY WITH THE WEBDYNSUN GATEWAY

Different brands of inverter may be connected to the RS485(B) port or via the Ethernet port if the inverter protocol is based on the Modbus protocol (RTU or TCP).

However, different brands of inverters cannot be connected to the same RS485(A) port.

For a list of compatible inverters, please see the product page of the WebdynSun data gateway
  • Check if the correct inverter protocol is selected before starting detection:
  • Check the wiring and configuration of the inverters by referring to the inverter appendices.
  • Check that the inverters are not in OFF or stand-by mode.
  • Check that the line end plugs on the RS 485(A) Bus are turned on.

COMPATIBILITY WITH MODBUS DEVICES

Yes, any device you wish to connect must be configured and its Modbus definition file must be created.

The configuration is mainly based on the RS485 serial bus parameters and the IP parameters.

Yes, different Modbus devices can be connected to the same RS485 (B) port.

However, they must have the same communication parameters (bus parameters or compatible IP parameters), in order for them to communicate with each other.