Tunnel – General Configuration parameters “MTX_”

Suchen Sie etwas anderes?

Tunnel – General Configuration parameters “MTX_”

All general configuration parameter starts with “MTX_” prefix string.

MTX_PIN, MTX_PIN2

Description: PIN secure number of SIM inserted. Possible values:

  • 16 characters maximum
  • Default value: 0000

Additional notes:

  • In case of using a SIM card with no PIN number, MTX_PIN security code does not need any value
  • The MTX_PIN2 parameter is for exclusive use for models that have the “DUAL SIM” feature and refers to the Username used by the secondary SIM. In the case of the MTX-IOT-S family modems, the secondary SIM is the one inside the modem, accessible by opening the case

MTX_mode

Description: This is a very important parameter. It is needed to write the connection mode for MTX-Tunnel. MTX-Tunnel can wait for an incoming connection if it is a TCP socket server. Value is server. If MTX-Tunnel connects to a remote server then it is a TCP socket client. Value is client. If MTX-Tunnel uses UDP protocol for socket communication, value is udp. If you do not need any GPRS-Serial tunnel Gateway use value “none.” Possible values:

  • server, client, udp, none
  • Default value: server

Additional notes:

  • By using “none” as the value you can use MTX-Tunnel for SMS and other telemetry applications, but no 2G/3G/4G connection will be made. See annex 2 with many example scenarios to understand this parameter

MTX_urc

Description: MTX-Tunnel can output in COM1 (ASC0) the status of connections or working state of MTX-Tunnel as URC –Unsolicited Result Codes- messages. URC messages can be:

^MTXTunnel_9.x_running

First message after powering up MTXTunnel. It means it is in running mode.

^MTX_IP_XXX.XXX.XXX.XXX

Message when MTXTunnel has got a new IP address in a GPRS connection.

^MTX_DTR_END_APPLICATION

This message is outputted when the MTX-Tunnel application has been stopped by a user request (special AT command or DTR serial line change level).

^MTX_CONNECTION_CLIENT_ESTABLISHED

Output message when MTX-Tunnel configured as client has connected successfully with the remote server.

^MTX_CONNECTION_CLIENT_END

Output message when a client configured MTX-Tunnel has closed the connection with the remote server because it has disconnected itself or because the socket has been closed remotely.

^MTX_CONNECTION_ESTABLISHED

Output message when MTX-Tunnel is server mode configured and accepts a remote socket connection…

^MTX_CONNECTION_END

Output message when MTX-Tunnel configured as server has closed the connection with the remote equipment because it has disconnected itself or because the socket has been closed remotely.

^MTX_SOCKET_UDP_ESTABLISHED

Output message when MTX-Tunnel configured as “udp” is ready to send and receive UDP data.

^MTX_SOCKET_UDP_END

URC message will be shown when MTX-Tunnel configured as “udp” closes the UDP socket due to a normal request (for example, time for GPRS connection has been expired).

^MTX_BITCOIN_INCOME_

This message is to be shown when the MTX-Tunnel is configured to receive payments using bitcoin. See annex for more information. Possible values:

  • on, off
  • Default value: off

Additional notes:

  • We recommend you to not activate URC messages unless necessary. In a normal GPRS-Serial RS232 tunnel Gateway these messages are in the same RS232 Serial port so there can be interference in the communication
  • The first time when configuring and testing MTX-Tunnel it can be useful to see what MTX-Tunnel is doing or get information like the newly obtained IP address

MTX_reset

Description: Time parameter (in minutes) so that MTX-Tunnel can be reset automatically. A value of “0” indicates that the modem will never be automatically reset. Possible values:

  • 0… 43200 (43200 minutes=30 days)
  • Default value: 0
  • “0” disable this feature and MTX-TUNNEL will not be reset periodically.

Additional notes:

  • It is not recommended to use this parameter unless you think it is necessary. MTX-Tunnel features many automatic procedures to ensure GPRS connection will be stable and working 100% of the time.

MTX_resetHour

Description: This parameter can perform an automatic reset at a specific time X. Once reset, the MTX-Tunnel will restart automatically. A value of “99” will cause the modem to never reset itself at any time. Possible values:

  • 0… 23-99
  • Default value: 99

Additional notes:

  • “99” value disables this feature; modem will be never automatically reset
  • It is not recommended to use this feature unless you think it is necessary; MTX-Tunnel has internal procedures allowing GPRS connectivity to always be on…
  • You need to use the MTX_TPServer parameter and use a timing server. The modem will synchronize internal time with server time TP protocol based
  • Modem time format is HOUR UTC
  • If you enable this parameter, please use also MTX_reset parameter at 25 hours. This way reset will be performed and all services are restored even if timing synchronization fails

MTX_ping

Description: This is a very important configuration parameter to ensure GPRS connectivity. MTX-Tunnel will perform a PING to a configured IP address at configured periodic second timing. If value is “0” PING will be never performed. Possible values:

  • 0… 1440 (1 day)
  • Default value: 30

Additional notes:

  • We recommend using MTX_PING with a least 30 minutes value
  • This parameter is more important if MTX-Tunnel is used in “server” mode. In this mode, MTXTunnel is waiting for incoming connections from remote equipments, and network operators can block the PPP connection without any notice. MTX-Tunnel cannot detect this block as there is no traffic so we use PING protocol to detect if the PPP connection is alive. PING traffic is almost insignificant and you could avoid the network operation PPP blocking when there is no traffic transmission

MTX_pingIP

Description: In the case of the above parameter MTX_ping > 0, i.e. when periodic ping is activated, this parameter value defines the PING IP address to be performed. If you do not use this parameter, MTX-Tunnel will perform PING to its own IP address. Be careful, some network operators do not allow performing PING to the newly obtained IP address, so we recommend you use a well known IP address. You can use your own server/office IP or the DNS Google one which is 8.8.8.8. Possible values:

  • xxx.xxx.xxx.xxx or you can use a URL like google.com
  • Default value: MTX-Tunnel obtained IP

Additional notes:

  • We recommend that you use PING methods when using permanent connections

MTX_portAux

Description: Most part of the MTX modem family have two COM serial ports, COM1 y COM2. If you activate this parameter with the value “on”, external equipment connected to COM2 could send AT commands.

Possible values:

  • on, off, modbusmaster, gateway, bypass, wmbus
  • Default value: off

Additional notes:

  • If you are not going to use this feature, disable this parameter with the value “off” as it will save internal CPU resources
  • This parameter must be “off” when using MTX-Terminals that only have one COM1 port
  • Read AT commands that can be used. Please read the MTX_ATLimited parameter
  • From MTX-Tunnel version 5.6, “wavenis” can be used as the parameter to control RF Wavenis protocol based devices connected to COM2
  • From MTX-Tunnel version 7 “modbusmaster” can be used as the parameter to read RTU modbus devices connected to COM2. Read LOGGER_, MODBUS_ parameter description for more information
  • From MTX-Tunel version 7.10 “gateway” can be used as the parameter to act as a gateway between the serial ports of the modem when there is no GPRS or GSM connection established. All data that enters the COM1 part is redirected to the COM2 port and vice versa
  • From MTX-Tunnel version 9-20 it has a “bypass” functionality. This option is very similar to the option “gateway” but with preference for the serial gateway regarding the serial 3G gateway
  • As of version MTX-Tunnelv11.14 it has the option “wmabus”. This option configures the modem to be able to read wmbus devices, as long as the modem has an appropriate internal RF card

MTX_portAuxEcho

Description: Enable MTX_portAux parameter “on” value when you need echo AT commands in COM2 port. Possible values:

  • on, off
  • Default value: on

Additional notes:

  • This parameter is only valid when MTX_portAux is enabled (“on”). If not, this will not used

MTX_IDClient

Description: If MTX-Tunnel is configured in client mode (MTX_mode value parameter “client”), MTX-Tunnel sends an identification string when the connection with the server is done. This string is the first to be sent after the connection with the remote server. This is intended to identify MTX-Tunnel with the server, and is useful when dynamic IP addressing is used. Possible values:

  • Text string 255 characters max.
  • Default value: (empty, nothing is sent)

Additional notes:

  • If you leave the value empty MTX-Tunnel will not send an identification string

MTX_IDClientExtended

Description: By enabling this parameter with the value “on” and using identification string with MTX_IDClient parameter, it is possible to send more information to a remote server. When MTX_IDClientExtended is “on”, the extended string has the following format: MTX_IDClient#IMEI#gpio1#gpio2# … #gpio10#adc1#adc2# MTX_IDClient is configuration string, IMEI is modem identifier, and gpioX is digital input/output and is analog input. NOTE

  • With new models MTX-3G-Java-IoT and MTX-3G-Java-IOT the string will have the value of the pulse counter 1 and pulse counter 2 MTX_IDClient#IMEI#gpio20#gpio21#gpio22#gpio23#adc1#adc2#counter1# counter2# If I/O are not needed and you set the parameter MTX_IDClientExtended “imei”: MTX_IDClient#IMEI# MTX_IDClient is configuration string, IMEI is modem identifier

Possible values:

  • on, off, imei
  • Default value: off

Additional notes:

  • If you leave the value empty MTX-Tunnel will not send an identification string

MTX_IDClientPeriod

Description: MTX_IDClient information string is only sent after the client connection to the remote server once after every new connection. With this parameter IDClient can send the information periodically every X seconds; for this, just use a value >0. Possible values:

  • 0 … 2592000 (30 days)
  • Default value: 0 (only one string is sent at connection)

Additional notes:

  • This can be useful if you need to remotely monitor the input/outputs and analog input because their statuses are sent periodically

MTX_dtr

Description: In some scenarios you may need to stop the MTX-Tunnel application. Then the modem would work with normal AT commands so you would be able to make a CSD call or voice call for example. There are two ways to stop MTX-Tunnel:

  • Send a proprietary AT command (AT^MTXTUNNEL=EXIT)
  • Use modem DTR line on COM1 serial port. This feature must be enabled with the parameter value at “on”

Possible values:

  • on, off
  • Default value: off

Additional notes:

  • You can start MTX-Tunnel again using AT+CFUN=1, 1 command (recommended). Also you can use AT^SJRA=”A:/MTXTunnel.jar” command

MTX_TPProtocol

Description: Parameter available since MTX-Tunnel version v9.30. Previus versions can only use “tp” servers. It allows to choose the time sync protocol between “tp (Time Protocol)” and “ntp (Network Time Protocol).” Possible values:

  • Tp, ntp
  • Default value: tp (for compatibility reasons for previous versions)

Additional notes:

  • Time servers give URG time, so when it is used by a modem it is also UTC time (please take into account what UTC time is your region on. For example, in Spain it’s UTC+1 or UTC+2 in the summer)

MTX_TPServer

Description: MTXTunnel can be timing synchronized using TP (Time protocol) or NTP (Network Time Protocol) since MTX-Tunnel v9.30. we can choose the protocol with the parameter MTX-TPProtocol. It connects to timing servers and fixes the RTC (Real Time Clock) deviation errors. Also it gets the time after power up. It can be used on private or own time servers, but they are many free time servers and they can be used on MTX-Tunnel like this. For example, if MTX_TPProtocol has “tp” value we can choose between these time servers:

time-a.timefreq.bldrdoc.gov time-a.timefreq.bldrdoc.gov time-b.timefreq.bldrdoc.gov time-c.timefreq.bldrdoc.gov utcnist.colorado.edu time-nw.nist.gov nist1.nyc.certifiedtime.com nist1.dc.certifiedtime.com nist1.sjc.certifiedtime.com nist1.datum.com ntp2.cmc.ec.gc.ca ntps1-0.uni-erlangen.de ntps1-1.uni-erlangen.de ntps1-2.uni-erlangen.de ntps1-0.cs.tu-berlin.de time.ien.it ptbtime1.ptb.de ptbtime2.ptb.de > recommended as public free one tp1.mtxm2m.com

If we select “ntp” in MTX_TPProtocol we can choose any NTP server. For example: 0.es.pool.ntp.org, 1.es.pool.ntp.org Possible values:

  • Text string < 255 characters
  • Default value: none

Additional notes:

  • Please note time server’s returns UTC time and there are a few hours difference in your country. As an example, in Spain the time is UTC+1 or UTC+2 in summer. UTC 09.00 time in July is 11.00 local time in Spain
  • From MTX-Tunnel v7.15, this parameter can be specified as “null”. By doing this, the modem takes its current time as valid, without consulting an external server.This can be useful in situations where the WAKEUP_ parameter is used, whereby an activity must be carried out at certain intervals and the actual time is not really important

MTX_TPServer2

Description: Backup timing server. If the previous main time server fails, MTX-Tunnel will take this second one as a security backup. If MTX_TPProtocol is “tp” we can choose from these time servers:

time-b.timefreq.bldrdoc.gov time-a.timefreq.bldrdoc.gov time-b.timefreq.bldrdoc.gov time-c.timefreq.bldrdoc.gov utcnist.colorado.edu time-nw.nist.gov nist1.nyc.certifiedtime.com nist1.dc.certifiedtime.com nist1.sjc.certifiedtime.com nist1.datum.com ntp2.cmc.ec.gc.ca ntps1-0.uni-erlangen.de ntps1-1.uni-erlangen.de ntps1-2.uni-erlangen.de ntps1-0.cs.tu-berlin.de time.ien.it ptbtime1.ptb.de ptbtime2.ptb.de tp1.mtxm2m.com > recommended free public time server

If we select “ntp” in MTX_TPProtocol we can choose any NTP server. For example: 0.es.pool.ntp.org, 1.es.pool.ntp.org Possible values:

  • Text string < 255 characters
  • Default value: None

Additional notes:

  • You can use this backup timing server only if you have configured main in MTX_TPServer parameter

MTX_ATMux

Description: This parameter, when enabled, activates the multiplexer on the COM1 serial port of MTX-Tunnel. Multiplexer means it is possible to send AT commands to a modem when a GPRS-RS232 tunnel is active/connected. This way you can use AT commands to see network overage/information, change or read a digital output/input, stop MTX-Tunnel or change a configuration parameter. You need to write AT commands into special tags strings because MTX-Tunnel has to interpret it and not send it to the GPRS using following syntax: <MTXTUNNEL> </MTXTUNNEL> Example: <MTXTUNNEL>AT+CSQ</MTXTUNNEL> MTXTunnel will return: <MTXTUNNEL>AT+CSQ +CSQ: 22, 99 OK</MTXTUNNEL> Possible values:

  • on, off
  • Default value: off

Additional notes:

  • Special AT command must be sent with a pause of 1 second after last data sent on serial port but there can be no pauses of more than 50ms between characters
  • Read chapter 7 to know more information about which AT commands are allowed in this multiplexer mode

MTX_WatchdogOnExit

Description: MTXTunnel features watchdog. If enabled, MTX-Tunnel must internally refresh the watchdog every 300 seconds (5 minutes). In case this refresh fails, the internal software watchdog will reset the MTX-Tunnel application. If MTX-Tunnel is stopped (you can stop it using DTR or by AT commands), watchdog remains active, meaning that after 5 minutes, MTX-Tunnel will be reset and so, starts again. If you disable this feature with an “off” value, watchdog will never reset MTX-Tunnel, even if it is ended. Possible values:

  • on, off
  • Default value: on

Additional notes:

  • This is useful when the user needs to stop MTX-Tunnel temporarily to do certain classic modem communications (voice or data call, SMS….) and then if “on” ensure that MTX-Tunnel is running after 5 minutes

MTX_model

Description: very important and mandatory parameter which specifies which MTX-Terminal modem model will run the MTX-Tunnel application. Its use is completely necessary. You can enter the name of the equipment or part number. Both can be found on the sticker at the bottom of any MTX modem.

 MTX-2G-T  MTX-2G-T
MTX-2G-Java-IoT-STD-N MTX-2G-JAVA-IOT-STD-N
MTX-3G-Java-IoT-STD-N (EHS6) MTX-3G-JAVA-IOT-STD-N
MTX-3G-Java-IoT-STD-G (EHS8) MTX-3G-JAVA-IOT-STD-G
MTX-3G-Java-IoT-STD-A MTX-3G-JAVA-IOT-STD-A
MTX-4G-Java-IoT-STD-N MTX-4G-JAVA-IOT-STD-N
MTX-4G-Java-IoT (USA-AT&T) MTX-4G-JAVA-IOT-STD-N
MTX-4G-Java-IoT-STD-N (AUS) MTX-4G-JAVA-IOT-STD-N
MTX-3G-Java-T MTX-3G-JAVA-T
MTX-3G-Java-T2 MTX-3G-JAVA-T2
MTX-3G-Java-T-G MTX-3G-JAVA-T-G
MTX-3G-Java-T-S MTX-3G-JAVA-T-S
MTX-4G-Java-T (4G/2G) MTX-4G-JAVA-T
MTX-4G-Java-T (4G/3G/2G) MTX-4G-JAVA-T
MTX-4G-Java-T2 MTX-4G-JAVA-T2
MTX-4G-Java-T (USA-AT&T) MTX-4G-JAVA-T
MTX-4G-Java-T (AUS) MTX-4G-JAVA-T
MTX-4G-Java-IoT-STD-N-WC868 MTX-4G-JAVA-IOT-STD-N-WC868
MTX-4G-Java-IoT-STD-N-RL MTX-4G-JAVA-IOT-STD-N-RL
MTX-4G-Java-IoT-STD-N-GPS MTX-4G-JAVA-IOT-STD-N-GPS
MTX-4G-Java-IoT-STD-N-ULP MTX-4G-JAVA-IOT-STD-N-ULP

Default value: none Additional notes:

  • Example: you have an MTX called “MTX-4G-Java-IoT-STD-N (AUS).” The value you can enter is: MTX_model: MTX-4G-JAVA-IOT-STD-N or MTX_model: 199801446
  • Please ensure to check this mandatory parameter due to each model’s specific I/O configuration. If you do not write the correct value, MTX-Tunnel may not work properly in any related with input/outputs features (like SMS alarm-control)

MTX_ATLimited

Description: This optional parameter can disable the limitation of AT command execution if the value is “off”. Remember you can use AT commands (multiplex on COM1, COM2, or via SMS or HTTP). Possible values:

  • on, off
  • Default value: on

Additional notes:

  • We recommend that you set this parameter to “on”. Only use “off” when you need to use another command, but keep in mind that using AT commands without limitation could interfere with MTX-Tunnel behaviour. Please read AT command set of MTX-Terminals or ask iotsupport@mtxm2m.com for more information

MTX_clientSSL

Description: Allows SSL secure socket communication (only client mode MTX_mode: client). Remote server needs to support secure SSL socket connection. Possible values:

  • on, off
  • Default value: off

Additional notes:

  • It is only possible to use an SSL security socket when MTX tunnel is used in client mode
  • Do not use this if it is not necessary. Traffic data volume is increased and data communication speed will be slower
  • The server must support any of following SSL standards
  • TLP protocol version 1.0 (RFC 2246)
  • SSL v3.0
  • WAP TLS Profile and Tunneling Specification

MTX_temporalClient

Description: This parameter allows you to establish a temporal client socket when MTX-Tunnel is in server mode (MTX_mode: server) and there is no connection established. Example scenario: A series of MTX-Tunnel modems are available. Each MTX Tunnel has a weather station on its COM1 serial port. All MTX-Tunnel are configured in “server” mode, since they are meant to establish a periodic connection from a central PC to collect the historical of temperatures of each meteorological station. This allows critical alarm values to be sent without waiting for incoming server connections. After one minute (enough time to send the alarms), the socket is closed and MTX-Tunnel remains in normal server mode. Possible values:

  • on, off
  • Default value: off

Additional notes:

  • This temporal tunnel connection takes just one minute, if there is no data traffic, the socket will be closed
  • When the temporal socket is activated, the socket server services (server socket, WebServer….) are also activated. But if the temporary socket is closed after one minute, the associate services are closed after GPRS_timeout parameter
  • The temporal client socket can be activated if the GPRS connection is always active (GPRS_timeout=0) or not (GPRS_timeout>0)
  • If there is already a GPRS connection (socket connected to MTX-Tunnel) it is not possible to start the temporal client socket
  • If the temporal client socket is running it is not possible to start server mode and any incoming connections will be not allowed
  • It is MANDATORY that the MTX_ATMux parameter is disabled “off”, if not the temporal client socket connection will be not started
  • From MTX-Tunnel v7 is it also possible to use a special AT remote commands to start the temporal client socket

MTX_msToSend

Description: A pause that indicates how many milliseconds must pass without receiving data through the serial port for the MTX-Tunnel to send data via GPRS. Possible values:

  • 0 … 5000
  • Default value: 50

Additional notes:

  • This is useful if the equipment connected to serial COM and MTX-Tunnel do not send data in concatenated way. Communication will be slower but all data is compacted

MTX_gatewayModBus

Description: This parameter will configure MTX-Tunnel as ModBus TCP/Modbus RTU tunnel gateway. MTX-Tunnel must be configured in server mode. Possible values:

  • on, off, comm, comm2
  • Default value: off

Additional notes:

  • Remember MTX-Tunnel must be in server mode, waiting for TCP connection. See Annex 2, example 2.14
  • The comm, comm2 parameters are available from version 11.08 of the MTX-Tunnel and are useful when the modem has 2 IP-Serial gateways configured.
    An “on” value means that if the modem has two IP-Serial gateways configured, both act as modbus TCP / RTU gateways.
    A “comm” value makes only the main serial port (the one associated with COMM_ parameters) act as a modbus TCP / RTU gateway, with the secondary serial port (the one associated with COMM2_ parameters) acting as transparent gateway.
    A “comm2” value makes only the secondary serial port (the one associated with the COMM2_ parameters) act as a modbus TCP / RTU gateway, with the main serial port (the one associated with the COMM_ parameters) acting as a transparent gateway.

MTX_alwaysConnectedClient

Description: If MTX-Tunnel is configured in client mode (MTX_mode:Client), this parameter establishes a TCP socket connection once (value “off”) or in case the socket is closed, the connection is retried every 30 seconds (value “on”). Possible values:

  • on, off
  • Default value: on

Additional notes:

  • “off” value is intended for the server to collect all data and close the socket. MTX-Tunnel will not retry in 30 seconds to open the socket, which will save resources in the server
  • Parameter only valid if MTX-Tunnel is in client mode

MTX_init1, MTX_init2, MTX_init3

Description: These 3 parameters can execute AT commands after MTX-Tunnel starts or powers up. As an example, one AT command could be sending an SMS when the modem is switched on. Possible values:

  • AT command text string
  • Default value: none

Additional notes:

  • This can be used in many end applications and helps in a special start-up. Please check the AT commands manual or ask iotsupport@mtxm2m.com for further information

MTX_ATEmbedded

Description: this parameter allows the modem to interpret AT commands received by a client socket. That is, if this parameter is “on” from the server itself, AT commands can be sent to the MTX-Tunnel encapsulated between the tags: and . You can check the coverage, change settings… Very useful in the case of using socket type “client”. Possible values:

  • on, off, temporalclient
  • Default value: off

Additional notes:

  • If you send an embedded AT command through a socket, you will also receive the response between the tags
  • This mode of sending embedded AT commands allows you to bypass firewalls and proxies that many telephone operators use. If you cannot use Telnet to send remote AT commands to your MTX-Tunnel because your operator prevents it, use this route. Valid for both client, server and temporary client sockets
  • The “temporaryclient” value option is only available from the MTX-Tunnel v10.18 version. If you set this value and the modem is set to (MTX_mode: server), only the AT ^ MTXTUNNEL = DEFAULTTEMPORALCLIENT command can be executed. Refer to the meterind example (meter reading) 7 of annex 6 for more information

MTX_radioBand

Description: This parameter can specify the preferred radio bands the modem will connect to. This is not really necessary in most cases, but in some countries in South America it is recommended to set this parameter. Possible values:

  • none, europe, america
  • Default value: none

Additional notes:

  • If your modem is going to be used in Europe use “none” or “europe” value
  • If your modem is going to be used in an American country, use “america” value
  • Only available for MTX-65i modems family

MTX_invertedCom

Description: This parameter will invert COM values on MTX-Terminal modems with 2 serial COMS. As an example, MTX65i has two RS232 serial ports and MTX-65i-RS485 has one RS232 and another RS485. If MTX_invertedCOM is enabled (value “on”) the secondary COM2 port now will act as COM1 and vice versa. Possible values:

  • on, off
  • Default value: off

Additional notes:

  • This could be useful if you principally need the COM2 port of MTX-65i-RS485
  • Please note that RS485 serial COM of MTX-3G-Java-IOT-STD-N modem is the secondary com. If you need to use it as primary (eg to attend a GSM call) must use MTX_invertedCom to “on”

MTX_flushSerialBuffers

Description: This parameter allows you to clean the serial buffers of any data to be sent before connecting to the TCP/IP socket. This means that if you have some outstanding serial data, it is removed by the modem’s buffers before establishing the GPRS-serial gateway. Possible values:

  • on, off
  • Default value: off

MTX_ATEmbeddedPass

Description: With the MTX_ATEmbeddedPass parameter set to “on” it is possible to send configuration AT commands in its own GPRS-serial gateway. With MTX_ATEmbeddedPass it is possible to set a password for embedded AT commands for enhanced security. Possible values:

  • String of up to 32 characters
  • Default Value: none

Additional notes:

  • If you set a password for the MTX_ATEmbeddedPass parameter, you will have to specify the password when you send an embedded AT command
  • For example you need to send the command AT+CSQ. If you do not set a password you could send this <MTXTUNNELR>AT+CSQ</MTXTUNNELR>, but if you have set your password as XXX you will need to send <MTXTUNNELR XXX>AT+CSQ</MTXTUNNELR> which means you need to send: <MTXTUNNELR[space][password]> ATcommand</MTXTUNNELR>

MTX_clientReconnection

Description: This parameter is useful for configuration scenarios in which client connections are present (MTX_mode: client). In these scenarios this parameter specifies when the MTX-Tunnel will retry the connection after a shutdown by the remote server. Possible values:

  • 0 … 86400 (seconds)
  • Default Value: 30

Additional notes:

  • Note that if you set the value with a very low number (e.g. 0), MTX-Tunnel will retry the connection very quickly if there are constant problems or failures with the remote server and this will increase bandwidth

MTX_urcPort

Description: Parameter available from MTX-Tunnel v7.15. Sets the output port of URC messages. Possible values:

  • asc0, asc1 y usb
  • Default value: asc0

Additional notes:

  • The “asc0” value refers to main serial port (COMM_)
  • The “asc1” value refers to the secondary serial port (COMM2_ )
  • The “usb” value refers to usb port

MTX_clientTimeout

Description: Parameter available from version MTX-Tunnel v7.15. It allows you to specify the time, in seconds, that must be taken to close a client socket in the case of no GPRS data exchange. Possible values:

  • 30… 86400
  • Default value: 1800 (30 minutes)

MTX_serverTimeout

Description: the parameter is available from MTX-Tunnel v9.18. It allows to specify the time in seconds. A server TCP Socket (for a 2G/3G/4G-serial gateway) will be closed in case there is no data transmission via 2G/3G/4G. Possible values:

  • 0… 86400
  • Default value: 0 (not activated)

Additional notes:

  • This parameter is not necessary for the majority of scenarios. Its value can be 0 for most of them
  • Where this parameter matters is in those scenarios where a serial port is used for two simultaneous tasks: autonomous reading of modbus registers + 2G/3G/4G-Serial gateway. That is to say, scenarios where the autonomous reading of modbus registers is suspended when a 2G/3G/4G-serial gateway is set up by the same serial port for a real-time action. The example 6.10 of this manual shows a typical case of the use of this parameter

MTX_rssiLow

Description: parameter valid from version MTX-Tunnel v10.00. This parameter will start working if the parameter MTX_redLed or MTX_greenLed have selected the option “rssi.” If so, a coverage value under this range (MTX_rssiLow) will make the coverage LED to blink every 3 seconds indicating low signal level. Possible values:

  • 0… 31
  • Default value: 10

Additional notes:

  • The values of a modem coverage level are standardized between 0 and 31, with 0 as the worst value and 31 as the greatest coverage
  • The modem updates the status of its coverage LED every 10 seconds
  • In case coverage is between the values MTX_rssiLow and MTX_rssiHigh, the coverage LED will indicate it with 2 blinks every 3 seconds

MTX_rssiHigh

Description: parameter valid from version MTX-Tunnel v10.00. This parameter will start working if the parameter MTX_redLed or MTX_greenLed have selected the option “rssi.” If so, a coverage value over this range (MTX_rssiLow) will make the coverage LED to blink 3 times every 3 seconds indicating high signal level. Possible values:

  • 0… 31
  • Default value: 20

Additional notes:

  • The values of a modem coverage level are standardized between 0 and 31, with 0 as the worst value and 31 as the greatest coverage
  • The modem updates the status of its coverage LED every 10 seconds
  • In case coverage is between the values MTX_rssiLow and MTX_rssiHigh, the coverage LED will indicate it with 2 blinks every 3 seconds

MTX_greenLed

Description: parameter valid from version MTX-Tunnel v10.00. This parameter determins the behavior of the equipment green LED. Configured as “std” the behavior of the green LED is the standard Gemalto chipset (slow blink when the modem isn’t registered on the network, quick blink when it is). Configured like “rssi” the LED will blink every 3 seconds when the coverage level is low (coverage<MTX_lowRssi), 2 blinks when the coverage level is normal (MTX_rssiLow<=coverage<MTX_rssiHigh) and 3 blinks when the coverage level is high (coverage>= MTX_rssiHigh). Possible values:

  • std, rssi
  • Default value: std

Additional notes:

  • Changing this parameter implies the equipment autoreset. That is, if you change the “std” value to “rssi” or viceversa, next time the modem starts it will autoreset once
  • The modem updates the status of its coverage LED every 10 seconds
  • The most interesting configuration is MTX_greenLed: rssi, MTX_blueLed: io2, MTX_redLed: sim

MTX_blueLed

Description: parameter valid from version MTX-Tunnel v10.00. This parameter determins the behavior of the equipment blue LED. Configured as “off” the blue LED won’t light up. Configured as “ip” the blue LED will light continually while the modem has IP (connection to a 2G/3G/4G data network). Configured as “ip2” the blue LED will blink every 3 seconds while the modem has IP (connection to a 2G/3G/4G data network). Possible values:

  • off, ip, ip2
  • Default value: ip

Additional notes:

  • If you use “ip2” you can also use MTX_greenLed ·rssi” since the blinking of the blue light happens moments after the coverage blinking, to ease the visualization
  • The modem updates the status of its coverage LED every 10 seconds
  • The most interesting configuration is MTX_greenLed: rssi, MTX_blueLed: io2, MTX_redLed: sim

MTX_redLed

Description: parameter valid from version MTX-Tunnel v10.00. This parameter determins the behavior of the equipment red LED. Configured as “off” the red LED won’t light up. Configured as “rssi” the red LED will behave like the MTX_greenLed when the value is “rssi.” Configured as “sim” the red LED will light up when: sim not inserted, incorrect sim pin, blocked sim (puk necessary). Possible values:

  • off, rssi, sim
  • Default value: off

Additional notes:

  • Using the value “sim” is interesting because it allows to detect and resolve some connectivity problems quickly, detecting that the problem is in the sim
  • The modem updates the status of its coverage LED every 10 seconds
  • The most interesting configuration is MTX_greenLed: rssi, MTX_blueLed: io2, MTX_redLed: sim

MTX_fullDuplex

Description: Parameter valid from version MTX-Tunnel v7.19. It allows you to improve the full-duplex capacity of the GPRS-Serie gateways. It is especially designed for applications NOT based in question-answer comunications but with independent transmissions/receptions. Possible values:

  • on, off
  • Default value: off (disabled)

Additional notes:

  • It is recommended to set it to “on” in the case of applications with independent asynchronous two-way communications. If you have a question/answer application (typical question from a server to whom the slave replies) do not activate this parameter
  • Activating this parameter will slightly improve the asynchronous two-ways communications but will penalize with time other services (Telnet, …)
  • If you are not sure about if activating or not this parameter, we advice you not to include it in the config.txt setting file

MTX_filter

Description: Parameter valid from version MTX-Tunnel v7.20 It allows you to use a filter in the 2G/3G/4G-Serie gateways (both in TCP server mode, as in TCP client and UDP modes). The use of a filter implies that, of the data frames received by the modem serial port, only those with a certain header will be sent via 2G/3G/4G. Possible values:

  • x,x,x,x… (bytes in header separated by a comma “,”)
  • Default value: none (no headers used)

Additional notes:

  • The header must be especified with bytes (decimal, no hexadecimal) separated by “,”
  • For example, if you only want to send the frames starting with “ABC”, the MTX_filter parameter in the setting file should be: MTX_filter: 65,66,67 as A corresponds to ASCII 65, B to 66, C to 67
  • Another example: if the MTX-Tunnel is connected to a red modbus and you are only interested in transmitting via GPRS the data frames to the MODBUS device with address 1, the MTX_filter parameter in the configuration file should be: MTX_filter: 1
  • If you do not need to use filters, simply do not include this parameter in the configuration file
  • Be aware you must take into account the MTX_msToSend parameter to use this parameter

MTX_latitude

Description: Parameter valid from version MTX-Tunnel v7.27 Specifies the latitude (relative to the GPS position, in decimal format) where the MTX-Tunnel is installed. This parameter is necessary when using the MTX-Tunnel astronomical clock, for example to switch a relay or for a digital output automatically at sunset/sunrise time. Possible values:

  • -90.00000 to 90.00000
  • Default value: none

Additional notes:

MTX_longitude

Description: Parameter valid from version MTX-Tunnel v7.27. Specifies the longitude (relative to the GPS position, in decimal format) where the MTX-Tunnel is installed. This parameter is necessary when using the MTX-Tunnel astronomical clock, for example to switch a relay or for a digital output automatically at sunset/sunrise time. Possible values:

  • -180.00000 to 180.00000
  • Default value: none

Additional notes:

MTX_configMode

Description: Parameter valid from version MTX-Tunnel v7.27. It allows you to choose if the “config” or “running” mode of the MTX-Tunnel is with or without the SIM inserted. That is, in “normal” mode (default mode) the MTX-Tunnel enters setting mode when the MTX is fed without a SIM card inserted and enters into “running” mode when it is fed with a SIM card inserted. In “reverse” mode the MTX enters “config” mode with a SIM card inserted and goes into“running” mode when there is no SIM card. Possible values:

  • -normal, reverse
  • Default value: normal

Additional notes:

  • Do not use the reverse mode if you are not sure what this parameter is for. It is only possible to use it in very specific scenarios
  • Use reverse mode only if you need the MTX-Tunnel for Logger without data delivery via 2G/3G/4G. That is, for example, to store the modbus records of a device during certain time in the modem internal memory. After this time, the modem is picked up and the “data.txt” file with the records stored is manually extracted
  • From MTX-Tunnel 9.39 on it is possible to use the value “modem” with the parameter MTX_configMode. That allows, also using MTX_ATMux in “modem” mode, to send AT commands also in configuration mode “when the modem doesn’t have a SIM card.” In other words, you will be able to configure via AT commands (AT^MTXTUNNEL=SETPARAM, etc.) without the need to load the file config.txt.

MTX_interface

Description: Parameter valid from version MTX-Tunnel v8.04 It allows you to choose the interface of communication between serial or USB. Possible values:

  • serial, usb
  • Default value: serial

Additional notes:

  • Parameter only available for 3G models. It can’t be used with GPRS models

MTX_encryptedConfig

Description: This parameter allows to encrypt the configuration file “config.txt”. If this parameter is set to “1”, the file “config.txt” will be encrypter after modem is power up. The “config.txt” file is different for each modem, so you can’t use the same encrypted “config.txt” file for any modem. If you need to use this option, it is very convenient to save the “config.txt” previously. Possible values:

  • 0, 1
  • Default value: 0

Additional notes:

  • This parameter is only supported from MTX-Tunnel v9.39

MTX_mes

Description: it allows to activate/deactivate the modem MES. That is, it allows to activate/deactivate the access to the internal memory of the modem. For example, it can prevent non authorized access to the configuration file “config.txt.” Remember you can also use the parameter MTX_encryptedConfig to encrypt the configuration. This MTX_mes parameter is a higher security level, that allows to block any access to the modem memory locally (USB, RS232). Possible values:

  • on, off
  • Default value: on (MES activated)

Additional notes:

  • This parameter is only supported from MTX-Tunnel v10.04
  • Be very careful with this command. If you set it off, after restarting the modem, the MES access will be blocked. The only way to unlock the access to the memory again will be sending the following commands:
AT^MTXTUNNEL=SETPARAM,MTX_mes,on
AT+CFUN=1,1

Then, have the precaution to test your access to the modem via Telnet, MQTT, SMS, etc. to the modem before blocking the memory.

MTX_resetCond

Description: this parameter allows that, in the case the modem is configured like a serial IP gateway (TCP server mode), and it gets the daily autoreset condition in the MTX_reset or MTX_resetHour parameter, the reset won’t happen when there’s a socket established against the modem and MTX_resetCond is in “socket” mode. Possible values:

  • off, socket
  • Default value: off

Additional notes:

  • This parameter can be very useful if the modem is configured to autoreset daily and is being used to make a serial IP gateway in server mode. Configuring this parameter like “socket” will avoid the modem resets while it’s being used as a gateway. The reset will perform when the socket finishes

MTX_status

Description: this parameter allows, in the case of being activated (on), to extract certain status information via one of the USB ports created by the MTX modem in Windows (the port COM USB associated with the modem). Possible values:

  • on, off
  • Default value: off

Additional notes:

  • This parameter can be useful to see the general status of the modem. It allows to see general aspects like the IP address obtained, the functioning network, the APN, the coverage, aspects of the BTS used, etc

MTX_numGSMErrors

Description: this parameter allows, when there are multiple registry problems in the network, to autoreset the modem after X periods of registry tries. Possible values:

  • 0 … 10000 (10 second blocks)
  • Default value: 0 (deactivated)

Additional notes:

  • MTX-Tunnel tries to register in the network and checks that registry every 10 seconds. If the established value for that parameter is > 0, after re-trying, the modem will autoreset. For example, if you specify a value of 90, if the MTX modem can’t register in the network in 90×10=900 seconds (15 minutes) the modem will autoreset. Although generally this parameter isn’t necessary, it can be in some conflictive areas, where there are BTS problems normally. A value of 180 is recommended for security reasons.

MTX_defaultPrefix

Description: this parameter allows to assign a prefix to an entering call without a prefix. Possible values:

  • Up to 8 characters
  • Default value: none (deactivated)

Additional notes:

  • For instance, if you call a modem located in Spain from a Spanish phone number located in Spain, the telephone number received by the modem won’t have the +34 prefix. If you configure the entering phone number as an authorized number (SMS_validPhone1), you will need to configure the parameter MTX_defaultPrefix to “+34” so that prefix can be added to the incoming number

MTX_temporalClientTimeout

Description: if a temporary TCP client socket is established, this parameter indicates how many seconds must pass without traffic on the socket (transmission or reception) for the temporary socket to close.

  • Possible values: 0… 3600 (seconds)
  • Default value: 60

Additional notes:

  • Parameter available since version 10.18. In previous versions the value is always 60 seconds

MTX_api232Resp

Description: This parameter is useful with the AT^MTXTUNNEL = RS232,… command. It allows you to specify whether the response collected by said AT command should be returned in ASCII or HEX format.
For example, if the command AT^MTXTUNNEL = RS232, … were used to send a command by SMS to the MTX modem which would be forwarded through the serial port to a device, and this would generate a response, said response would be forwarded literally when this parameter is in “ascii” mode or in hexadecimal when in “hex” mode. This is very useful when devices are outputting unrepresentable binary data in “ascii” format.

Possible values:

  • ascii, hex
  • Default value: ascii

Sie haben eine Frage? Sie benötigen ein Angebot? Kontaktieren Sie uns für ein Angebot.

  • Dieses Feld dient zur Validierung und sollte nicht verändert werden.

Anhänge und andere Dokumente

Annexes et autres documents

Anhänge und andere Dokumente

Anhänge und andere Dokumente

Anhänge und andere Dokumente

Anhänge und andere Dokumente

Anhänge und andere Dokumente

FAQ

Nein, das Gateway kann keine WM-Bus Daten entschlüsseln da es über keinen Safe verfügt um die Sicherheit des Schlüssels zu gewährleisten. Die empfangenen Daten werden ohne Modifizierung (ohne Entschlüsselung) durch das Gateway auf Ihrem Server abgelegt.
Bitte überprüfen Sie diese Punkte in nachstehender Reihenfolge:
  • den Batteriestand: Wenn die Batterie zu schwach oder leer ist, funktioniert das Produkt nicht richtig oder gar nicht.
  • Modem-Empfangsebene: ein schlechtes Signal am Modem kann verhindern, dass der Hub Dateien ablegt. Verlegen Sie das Produkt oder installieren Sie eine externe Antenne, um die Signalqualität zu verbessern.
  • Die letzte Konfigurationsdatei: Eine fehlerhafte Konfigurationsdatei kann das Produkt sperren.

Aus der Ferne können Sie die abgelegten Dateien regelmäßig überprüfen, um sicherzustellen, dass die Produktkonfiguration korrekt durchgeführt wurde.

Vor Ort fahren Sie mit dem Magneten über die Oberseite des Produkts und hören 3 kurze Pieptöne.

Ersetzen Sie das Produkt und übertragen Sie die Konfiguration des alten Produkts in das neue. Falls eine weiße Liste verwendet wird, vergessen Sie nicht, diese auch in das neue Produkt zu übertragen.

Anhänge und andere Dokumente

Andere Bedienungsanleitungen

Anwendungshinweise

FAQ

Konfigurieren des Gateways:

Prüfen Sie zunächst, ob die IP-Parameter des Computers mit der IP-Adresse von WebdynSunPM kompatibel sind (standardmäßig 192.168.1.12)

Starten Sie einen Webbrowser (Chrome, Firefox, Edge, Safari, …) und geben Sie die IP-Adresse des WebdynSunPM-Hubs in die Adresszeile ein. Eine Authentifizierungsseite wird angezeigt:

Die Standard-Login-Daten lauten:

KennungPasswort
userhighhigh

Klicken Sie auf „Login“

Die Konfiguration ist auf zwei Arten möglich, über die Web-Oberfläche und per SMS:
  • Konfiguration über die Web-Oberfläche:
Stellen Sie zunächst eine Verbindung zum Hub her, indem Sie sich anmelden, um auf die Serverkonfiguration zuzugreifen: Geben Sie den Verbindungsmodus „ethernet“ oder „modem“ ein: Stellen Sie bei einer Ethernet-Konfiguration sicher, dass die IP-Parameter mit dem Serverzugriff entsprechend der lokalen Netzwerkkonfiguration des Hubs kompatibel sind. Bei einer Ethernet-Verbindung muss die Konfiguration mit der lokalen Netztopologie des Hubs kompatibel sein, damit dieser auf die Server zugreifen kann. Diese Konfiguration erfolgt über die Konfigurationsseite „Networks“ (siehe Kapitel 3.2.2.3: „Netzwerke (Networks)“). Bei einer Modemverbindung muss das Modem korrekt konfiguriert sein, bevor eine Verbindung hergestellt werden kann. Diese Konfiguration erfolgt auf der Konfigurationsseite „Modem“ (siehe Kapitel 3.2.2.4: „Modem“). Die minimal zu konfigurierenden Serverparameter sind folgende: Diese Felder müssen konfiguriert werden: „Interface“, „Type“, „Server type“, „Address“, „Port“, „Login“ und „Password“. In den übrigen Feldern können die Standardwerte beibehalten werden, solange die Verzeichnisse zuvor korrekt angelegt wurden. Weitere Einzelheiten siehe Kapitel 3.1.2: Konfigurationsdateien“.
  • Konfiguration per SMS:
Die Konfiguration per SMS kann durch folgende Befehle vorgenommen werden:
    • Apn: zum Konfigurieren des APN der SIM-Karte. (siehe Kapitel 3.2: „Modem-Konfigurationsbefehl „apn““)
    • Ftp: zum Konfigurieren des FTP-Servers, der die Konfiguration des Hubs enthalten soll (siehe Kapitel3.3: FTP-Konfigurationsbefehl „ftp““).
    • Connect: zum Starten der Verbindung zum FTP-Server und zum Laden der Konfiguration (siehe Kapitel3.1: Verbindungsbefehl „Connect“ 

Die Zugangsdaten für den FTP-Server hängen von der gewählten Lösung ab.

Wenn Sie ein Portal gewählt haben, erhalten Sie die Zugangsdaten für den FTP-Server von diesem.

Wenn Sie einen eigenen FTP-Server verwenden möchten, wenden Sie sich bitte an Ihren Netzwerkadministrator.

Für alle anderen Konfigurationen und für die Auswahl der am besten geeigneten Lösung sollten Sie sich an die Webdyn-Vertriebsabteilung wenden, die Sie beraten und an die entsprechenden Ansprechpartner weiterleiten kann: contact@webdyn.com

Allgemeine Nutzung des Gateways

Es gibt 2 Methoden, um das Zurücksetzen auf die Werkseinstellungen des Hubs zu erzwingen:
  • Halten Sie die Taste Werksrückstellung am Hub für 20 Sekunden gedrückt:
Warten Sie. Der Hub startet nach ein paar Augenblicken mit der Werkseinstellung neu.
  • Wenn eine SIM-Karte installiert und konfiguriert ist, kann mit dem SMS-Befehl „factory“ auch eine Werksrückstellung durchgeführt werden. Senden Sie dafür einfach eine SMS mit dem Befehl „factory“ an die Rufnummer der SIM-Karte (siehe Kapitel 3.7: „Befehl Werksrückstellung „factory““)

Es ist möglich, Befehle an das angeschlossene Gerät zu senden, wenn letzteres diese akzeptiert.

Der WebdynSunPM speichert maximal 50MB unkomprimierte Daten pro definiertem Gerät.

Bei Nichtzugriff auf den Remote-Server kann der WebdynSunPM-Hub so Daten über mehrere Monate speichern.

Die maximale Datenspeicherzeit hängt von der zu erfassenden Datenmenge und der konfigurierten Erfassungshäufigkeit ab.

Die durchschnittliche Speicherzeit beträgt 3 bis 4 Monate.

Die durchschnittliche Lebensdauer der Batterie beträgt circa 5 Jahre.

Sie hängt vom Umfeld der Anlage ab.

Alle unsere Produkte haben eine Garantielaufzeit von 2 Jahren.

Weitere Informationen hierzu erhalten Sie in unseren Allgemeinen Geschäftsbedingungen.

Das Datenvolumen hängt von den ausgetauschten Dateien ab.

Der Durchschnitt liegt bei ca. 5 MB pro Monat und ist bei jeder Anlage anders.

Kompatibilität der Wechselrichter

Siehe Kapitel 1.4: „Unterstützte Geräte“.

Kompatibilität der Modbus-Geräte:

Ja, es ist möglich, verschiedene Modbus-Geräte an denselben seriellen Port anzuschließen.

Kompatibilität der Geräte:

  • Gleicher Verbindungstyp RS485 2-Draht oder 4-Draht.
  • Alle Geräte müssen mit identischen Buseigenschaften konfigurierbar sein. Gleiche Geschwindigkeit, gleiche Parität, gleiche Anzahl von Stoppbits und Datenbits auf allen Geräten und im WebdynSunPM.

Jedem Gerät muss eine eindeutige Modbus-Adresse (zwischen 1 und 247) auf dem Bus zugewiesen werden. (UnitID)

Anhänge und andere Dokumente

FAQ

 KONFIGURATION DES WEBDYNSUN-GATEWAYS

  • Überprüfen Sie zunächst, ob die IP-Einstellungen Ihres Computers mit der IP-Adresse des WebdynSun-Gateways kompatibel sind (Standard: 192.168.1.12).
  • Starten Sie anschließend einen Webbrowser (Firefox oder IE) und geben Sie die IP-Adresse des WebdynSun-Gateways in die Adressleiste ein. Eine Authentifizierungsseite wird angezeigt:

Die Standarddaten für den Zugang lauten:
Benutzername: userhigh
Passwort: high

  • Klicken Sie auf „Se connecter“ (Anmelden) 

Es gibt zwei Arten von Konfigurationen, über die Web-Schnittstelle und über SMS.

Konfiguration über die Web-Schnittstelle:
1/ Navigieren Sie zur Konfigurationsseite mit der IP-Adresse des Hubs (Standard 192.168.1.12)
2/ Gehen Sie zur Registerkarte „Configuration“ (Konfiguration).
3/ Wählen Sie den Verbindungsmodus Ethernet oder Modem:

Bei einer Verbindung über das LAN (Ethernet):

  • Ändern Sie die IP-Einstellungen des WebdynSun-Gateways, indem sie ihm eine netzwerkfähige Adresse zuweisen.

Beachten Sie, dass alle Felder gemäß der Konfiguration Ihres lokalen Netzwerks ausgefüllt werden müssen.

Bei einer Verbindung über das GPRS-Netz (Modem):

  • Ändern Sie die Verbindungseinstellungen des GPRS-Modems auf der Grundlage der von Ihrem Mobilfunkanbieter bereitgestellten Einstellungen.

4/ Editieren Sie die FTP-Server-Einstellungen.

5/ Bestätigen Sie die Änderungen.
6/ Starten Sie das WebdynSun-Gateway neu, damit die neuen Einstellungen berücksichtigt werden.
7/ Klicken Sie im Menü auf die Registerkarte „Installation“, dann auf die Unterregisterkarte „Connexion“ (Anmelden) und starten Sie die Verbindung.

Konfiguration über SMS:
Dieser Konfigurationsmodus erfordert die Verwendung einer aktiven SIM-Karte mit Datenoption und einem PIN-Code, der entweder „0000“ oder „deaktiviert“ sein muss.
Die SIM-Karte muss vor dem Einschalten des Geräts in das Gehäuse eingelegt werden.
Nach dem Einschalten des Geräts senden Sie die folgenden SMS an die Nummer der zuvor eingesetzten SIM-Karte:

Konfigurations-SMS des APN:
Nachdem Sie die generischen Felder durch die Felder Ihres Betreibers ersetzt haben, senden Sie die folgende SMS*:
apn=apn_name;usr=user_name;pwd=password;

Ersetzen Sie die Felder in der obigen SMS mit den folgenden Informationen:

  • apn_name: Name des APN, der von Ihrem Mobilfunkanbieter bereitgestellt wird
  • user_name: APN-Benutzername, der von Ihrem Mobilfunkanbieter bereitgestellt wird
  • password: APN-Passwort, das von Ihrem Mobilfunkanbieter bereitgestellt wird

 

SMS für FTP-Konfiguration:

Nachdem Sie die generischen Felder durch die Felder auf Ihrem FTP-Server ersetzt haben, senden Sie die folgende SMS*:
Ftp=server_name:user_name:password:port;

Ersetzen Sie die Felder in der obigen SMS mit den folgenden Informationen:

  • server_name: Adresse des FTP-Servers
  • user_name: Benutzername des FTP-Kontos
  • Password : Passwort des FTP-Kontos
  • Port : FTP-Server-Port (Standard-Port 21)

 

Anmelde-SMS:
Senden Sie per SMS* das Wort „connect“, um eine Verbindung zum FTP-Server zu initiieren

*Achtung: Die Formatierung der SMS muss strikt identisch mit der obigen sein (z. B. kein Leerzeichen zwischen den Zeichen, …)

 ALLGEMEINE NUTZUNG DES WEBDYNSUN-GATEWAYS

Es gibt 2 Methoden, um das Gateway zurückzusetzen.

Beim Verbindungsmodus Ethernet:

  • Trennen Sie das Gateway vom Netzstrom
  • Nehmen Sie den Deckel ab
  • Trennen Sie die Batterieverbindung
  • Setzen Sie den DIP-Schalter 2 der Karte des WebdynSun-Gateways auf die Position „ON“
  • Starten Sie das WebdynSun-Gateway, indem Sie es nur an den Netzstrom anschließen
  • Warten Sie, bis alle LED blinken und dann aufhören zu blinken (3 bis 5 Minuten)
  • Trennen Sie das Gateway vom Netzstrom
  • Stellen Sie den DIP-Schalter 2 auf „OFF“
  • Stellen Sie die Batterieverbindung wieder her
  • Stellen Sie die Verbindung mit dem Netzstrom wieder her; das WebdynSun-Gateway startet normal

Wenn eine SIM-Karte in den Hub eingesetzt ist:

  • Senden Sie eine SMS mit dem Wort „factory“ an die Nummer der eingesetzten SIM-Karte.

N.B.: Das Reset des Gateways stellt die Konfiguration in ihrem ursprünglichen Zustand wieder her. Achtung: Die Daten bleiben erhalten, jedoch nicht die spezifischen Einstellungen. Daher müssen alle Einstellungen neu konfiguriert werden.

Es ist möglich, Befehle an angeschlossene Geräte zu senden, außer an bestimmte Modbus-Wechselrichter oder -Slaves, die Schreibanforderungen nicht akzeptieren.

Für Geräte, die dies ermöglichen, können Auftragsdateien auf dem FTP-Server erstellt werden.

Die Speicherkapazität des WebdynSun-Gateways beträgt etwa 100 MB.
Wenn kein Zugriff auf den Remote-Server erfolgt, kann der WebdynSun-Hub die Daten daher mehrere Monate lang speichern.

Die maximale Zeit für die Datenspeicherung hängt von der Anzahl der zu erfassenden Daten ab.

Die durchschnittliche Backup-Dauer liegt zwischen 3 und 4 Monaten.

Die durchschnittliche Batterielebensdauer beträgt 5 Jahre.

Sie kann je nach Umgebung der Anlage variieren.

Ja, man kann Daten an einen Automaten senden, wenn dieser das Modbus-Protokoll integriert.

Die Konfigurationsdatei „Report“ (Bericht) ermöglicht es dem WebdynSun-Hub, die gelesenen Werte automatisch auf einen Modbus-Slave zu schreiben.

Wir gewähren auf alle unsere Produkte 2 Jahre Garantie.

Weitere Informationen finden Sie in unseren Allgemeinen Geschäftsbedingungen.

Die vom WebdynSun-Gateway hinterlegten Dateien werden im GZ-Format komprimiert.

Die in diesen Dateien enthaltenen Daten sind im CSV-Format strukturiert.

Das Datenvolumen hängt von den ausgetauschten Dateien ab.

Der Durchschnitt liegt bei etwa 5 MB pro Monat und variiert für jede Anlage.

 KOMPATIBILITÄT DER WECHSELRICHTER MIT DEM WEBDYNSUN-GATEWAY

Es ist möglich, Wechselrichter verschiedener Marken über den RS485(B)-Port oder über den Ethernet-Port zu verbinden, wenn das Protokoll der Wechselrichter auf dem Modbus-Protokoll (RTU oder TCP) basiert.

Es ist jedoch nicht möglich, Wechselrichter verschiedener Marken an denselben RS485(A)-Port anzuschließen.

Um die Liste kompatibler Wechselrichter in Erfahrung zu bringen, konsultieren Sie die Produktseite des WebdynSun-Datengateways.

  • Überprüfen Sie, ob das richtige Wechselrichter-Protokoll ausgewählt ist, bevor Sie die Erkennung starten:

  • Überprüfen Sie die Verkabelung und Konfiguration der Wechselrichter anhand der Anlagen zu den Wechselrichtern.
  • Vergewissern Sie sich, dass sich die Wechselrichter nicht im OFF- oder Standby-Modus befinden.
  • Überprüfen Sie, ob die Endkappen auf dem RS 485(A)-Bus aktiviert sind.

 KOMPATIBILITÄT MIT MODBUS-GERÄTEN

Ja, die zu verbindenden Geräte müssen konfiguriert und ihre Modbus-Definitionsdatei erstellt werden.

Die Konfiguration basiert hauptsächlich auf den seriellen RS485-Bus-Einstellungen oder den IP-Einstellungen.

Ja, es ist möglich, verschiedene Modbus-Geräte an denselben RS485-Port (B) anzuschließen.

Damit sie jedoch miteinander kommunizieren können, müssen sie dieselben Kommunikationsparameter (kompatible Bus-Einstellungen oder IP-Einstellungen) haben.

Anhänge und andere Dokumente

  • ACHTUNG: Für die alte Version mit SIM-Karte lautet der PIN-Code 0000. Sie können in dieser Version aktualisieren. Für den zweiten Fall: Wenn Sie eine SIM-Karte mit dem PIN-Code 0000 einlegen, der in dieser Version (4.07.02) verwendet wird, ist ein Downgrade auf eine frühere Version nicht zulässig.

Anhänge und andere Dokumente

  • ACHTUNG: Für die alte Version mit SIM-Karte lautet der PIN-Code 0000. Sie können in dieser Version aktualisieren. Für den zweiten Fall: Wenn Sie eine SIM-Karte mit dem PIN-Code 0000 einlegen, der in dieser Version (4.07.02) verwendet wird, ist ein Downgrade auf eine frühere Version nicht zulässig.

Anhänge und andere Dokumente

FAQ

Anhänge und andere Dokumente

FAQ

Anhänge und andere Dokumente

FAQ

Anhänge und andere Dokumente

FAQ

 KONFIGURATION DES WEBDYNRF-GATEWAYS

  • Wenn die Datei nach dem Verbinden des WebdynRF-Hubs aus dem Verzeichnis entfernt wird, liegt das Problem in der Regel an einem Fehler im Dateiformat. Die Konfigurations- und Befehlsdateien müssen das in den Schemadateien (XSD) beschriebene Format erfüllen. Um die Konsistenz eines Schemas zu überprüfen, öffnen Sie die XML-Datei mit dem Editor Notepad++ und installieren Sie das Add-in „XML Tool“. Kopieren Sie dann die XSD-Datei, die der XML-Datei entspricht, in dasselbe Verzeichnis, und wählen Sie im XML-Tool „Validate now“ (Jetzt bestätigen) aus. Die vom Tool erkannten Fehler müssen angezeigt werden.
  • Wenn die Datei nicht vom Server gelöscht wird, besteht das Problem meist darin, dass die Datei nicht an der richtigen Stelle abgelegt wurde. Die Datei muss auf dem Server im Verzeichnis „INBOX“ und im Unterverzeichnis mit dem Namen der Produkt-UID verfügbar sein (Beispiel: „/INBOX/0045CE/“).

ALLGEMEINE NUTZUNG DES WEBDYNRF-GATEWAYS

Die Menge der über das GPRS-Netzwerk ausgetauschten Daten hängt von der Konfiguration ab. Der Verbrauch kann auf etwa 5 MB/Monat geschätzt werden.
Der WebdynRF-Hub verbraucht durchschnittlich ca. 250 mA.

Es gibt 2 Modi für die Aktualisierung der Firmware:

Die lokale Aktualisierung:
Wechseln Sie auf der WebdynRF-Konfigurationsschnittstelle zur Registerkarte „Actions“ (Aktionen) und wählen Sie im Menü „File upload“ (Datei-Upload) den Updater aus, bevor Sie auf die Schaltfläche „Upload“ (Aktualisieren) klicken

Die Remote-Aktualisierung:
Laden Sie die Datei, die den Updater enthält (Datei mit der Erweiterung „.bz2“), auf den FTP-Server in das Verzeichnis „BIN“ hoch. Geben Sie dann den Aktualisierungsbefehl in das INBOX-Verzeichnis für Ihren Hub („INBOX/“ mit dem Benutzernamen des betreffenden Hubs).


Der Aktualisierungsbefehl muss folgendem Format entsprechen:

updater.tar.bz2
checksum_md5

updater.tar.bz2
checksum_md5

Mit :

  • updater.tar.bz2: Name der Updater-Datei, die in das Verzeichnis „BIN“ geladen wurde
  • checksum_md5: md5-Code der Updater-Datei

Eine fehlende Verbindung zum FTP-Server kann durch ein Problem mit der Netzwerkverbindung (Ethernet oder GPRS), ein Problem mit der FTP-Anmeldung oder durch die Nichtauslösung der Verbindung verursacht werden.

Falls Probleme mit der Netzwerkverbindung auftreten, überprüfen Sie Folgendes:

  • Ethernet:
    • Modem-Modus auf „off“ oder „alwaysoff“
    • „Gateway“-Feld korrekt eingegeben
    • Es muss mindestens ein DNS-Server konfiguriert sein
  • GPRS:
    • Modem-Modus auf „on“
    • APN, APN-Benutzername und APN-Passwort korrekt eingegeben
    • GPRS-Rufnummer auf „*99“ *1#“

 

Falls Probleme bei der Anmeldung auftreten, überprüfen Sie Folgendes:

  • Falsche FTP-Einstellungen
  • TCP-Port 21 geschlossen bei Ausgang
  • Problem bei der Auflösung des Domain-Namens: Der DNS-Server ist nicht näher spezifiziert

 

Bei Nichtauslösung der Verbindung:

In diesem Fall funktioniert nur die automatische Anmeldung nicht. Das Problem ist in der Regel auf eine schlechte Konfiguration der Zeitpläne zurückzuführen. Achtung, die ID der Zeitpläne muss eine Ganzzahl sein.

BESONDERE VERWENDUNG DES WEBDYNRF WIRELESS M-BUS-GATEWAYS

Für die Eskalation der Daten der WM-Bus-Module gehen Sie wie folgt vor:

  • Wählen Sie den Modus aus, der den verwendeten Modulen entspricht (S, T oder N)
  • Definieren Sie die Module oder Modulgruppen, die verarbeitet werden sollen

Ein Modul kann durch alle folgenden Felder eindeutig definiert werden:

  • Id
  • Manufacturer (Hersteller)
  • Version
  • Medium

Falls die Daten eines Moduls verschlüsselt werden, kann der Verschlüsselungsschlüssel für dieses Modul im Feld „Schlüssel“ festgelegt werden.

Um die Eingabe der zu verarbeitenden Module zu vereinfachen, kann eine Modulgruppe definiert werden, die die eingegebenen Felder erfüllt. Die anderen Felder bleiben dann leer (nachfolgend ein Beispiel für eine Konfiguration, mit der alle Module des Herstellers Webdyn (WDN) mit Verschlüsselungsschlüssel „00000000000000000000000000000000“ abgerufen werden können.)

  •   Id :
  •   Manufacturer (Hersteller): WDN
  •   Medium :
  •   Version :
  •   Label : Webdyn
  •   Key : 00000000000000000000000000000000

Hinweis: Damit die eingegebenen Module (Filter) berücksichtigt werden können, muss der Modus „Bypass filter“ (Bypass-Filter) deaktiviert werden.

 BESONDERE VERWENDUNG DES WAVENIS WEBDYNRF-GATEWAYS

Der Anschluss des Tools an den Hub erfolgt über den Installateurzugang (Install).

Es muss also das Passwort des Installateurs (standardmäßig „middle“) und nicht das des Administrators (standardmäßig „high“) verwendet werden.

Die Status, die vom WebdynRF-Hub eskaliert werden, sind die Rohwerte, die in den Wavenis-Modulen enthalten sind. Sie werden ohne Interpretation eskaliert. Weitere Informationen finden Sie in den Handbüchern der Coronis-Module.

Anhänge und andere Dokumente

FAQ

 KONFIGURATION DES WEBDYNRF-GATEWAYS

  • Wenn die Datei nach dem Verbinden des WebdynRF-Hubs aus dem Verzeichnis entfernt wird, liegt das Problem in der Regel an einem Fehler im Dateiformat. Die Konfigurations- und Befehlsdateien müssen das in den Schemadateien (XSD) beschriebene Format erfüllen. Um die Konsistenz eines Schemas zu überprüfen, öffnen Sie die XML-Datei mit dem Editor Notepad++ und installieren Sie das Add-in „XML Tool“. Kopieren Sie dann die XSD-Datei, die der XML-Datei entspricht, in dasselbe Verzeichnis, und wählen Sie im XML-Tool „Validate now“ (Jetzt bestätigen) aus. Die vom Tool erkannten Fehler müssen angezeigt werden.
  • Wenn die Datei nicht vom Server gelöscht wird, besteht das Problem meist darin, dass die Datei nicht an der richtigen Stelle abgelegt wurde. Die Datei muss auf dem Server im Verzeichnis „INBOX“ und im Unterverzeichnis mit dem Namen der Produkt-UID verfügbar sein (Beispiel: „/INBOX/0045CE/“).

ALLGEMEINE NUTZUNG DES WEBDYNRF-GATEWAYS

Die Menge der über das GPRS-Netzwerk ausgetauschten Daten hängt von der Konfiguration ab. Der Verbrauch kann auf etwa 5 MB/Monat geschätzt werden.
Der WebdynRF-Hub verbraucht durchschnittlich ca. 250 mA.

Es gibt 2 Modi für die Aktualisierung der Firmware:

Die lokale Aktualisierung:
Wechseln Sie auf der WebdynRF-Konfigurationsschnittstelle zur Registerkarte „Actions“ (Aktionen) und wählen Sie im Menü „File upload“ (Datei-Upload) den Updater aus, bevor Sie auf die Schaltfläche „Upload“ (Aktualisieren) klicken

Die Remote-Aktualisierung:
Laden Sie die Datei, die den Updater enthält (Datei mit der Erweiterung „.bz2“), auf den FTP-Server in das Verzeichnis „BIN“ hoch. Geben Sie dann den Aktualisierungsbefehl in das INBOX-Verzeichnis für Ihren Hub („INBOX/“ mit dem Benutzernamen des betreffenden Hubs).


Der Aktualisierungsbefehl muss folgendem Format entsprechen:

updater.tar.bz2
checksum_md5

updater.tar.bz2
checksum_md5

Mit :

  • updater.tar.bz2: Name der Updater-Datei, die in das Verzeichnis „BIN“ geladen wurde
  • checksum_md5: md5-Code der Updater-Datei

Eine fehlende Verbindung zum FTP-Server kann durch ein Problem mit der Netzwerkverbindung (Ethernet oder GPRS), ein Problem mit der FTP-Anmeldung oder durch die Nichtauslösung der Verbindung verursacht werden.

Falls Probleme mit der Netzwerkverbindung auftreten, überprüfen Sie Folgendes:

  • Ethernet:
    • Modem-Modus auf „off“ oder „alwaysoff“
    • „Gateway“-Feld korrekt eingegeben
    • Es muss mindestens ein DNS-Server konfiguriert sein
  • GPRS:
    • Modem-Modus auf „on“
    • APN, APN-Benutzername und APN-Passwort korrekt eingegeben
    • GPRS-Rufnummer auf „*99“ *1#“

 

Falls Probleme bei der Anmeldung auftreten, überprüfen Sie Folgendes:

  • Falsche FTP-Einstellungen
  • TCP-Port 21 geschlossen bei Ausgang
  • Problem bei der Auflösung des Domain-Namens: Der DNS-Server ist nicht näher spezifiziert

 

Bei Nichtauslösung der Verbindung:

In diesem Fall funktioniert nur die automatische Anmeldung nicht. Das Problem ist in der Regel auf eine schlechte Konfiguration der Zeitpläne zurückzuführen. Achtung, die ID der Zeitpläne muss eine Ganzzahl sein.

BESONDERE VERWENDUNG DES WEBDYNRF WIRELESS M-BUS-GATEWAYS

Für die Eskalation der Daten der WM-Bus-Module gehen Sie wie folgt vor:

  • Wählen Sie den Modus aus, der den verwendeten Modulen entspricht (S, T oder N)
  • Definieren Sie die Module oder Modulgruppen, die verarbeitet werden sollen

Ein Modul kann durch alle folgenden Felder eindeutig definiert werden:

  • Id
  • Manufacturer (Hersteller)
  • Version
  • Medium

Falls die Daten eines Moduls verschlüsselt werden, kann der Verschlüsselungsschlüssel für dieses Modul im Feld „Schlüssel“ festgelegt werden.

Um die Eingabe der zu verarbeitenden Module zu vereinfachen, kann eine Modulgruppe definiert werden, die die eingegebenen Felder erfüllt. Die anderen Felder bleiben dann leer (nachfolgend ein Beispiel für eine Konfiguration, mit der alle Module des Herstellers Webdyn (WDN) mit Verschlüsselungsschlüssel „00000000000000000000000000000000“ abgerufen werden können.)

  •   Id :
  •   Manufacturer (Hersteller): WDN
  •   Medium :
  •   Version :
  •   Label : Webdyn
  •   Key : 00000000000000000000000000000000

Hinweis: Damit die eingegebenen Module (Filter) berücksichtigt werden können, muss der Modus „Bypass filter“ (Bypass-Filter) deaktiviert werden.

 BESONDERE VERWENDUNG DES WAVENIS WEBDYNRF-GATEWAYS

Der Anschluss des Tools an den Hub erfolgt über den Installateurzugang (Install).

Es muss also das Passwort des Installateurs (standardmäßig „middle“) und nicht das des Administrators (standardmäßig „high“) verwendet werden.

Die Status, die vom WebdynRF-Hub eskaliert werden, sind die Rohwerte, die in den Wavenis-Modulen enthalten sind. Sie werden ohne Interpretation eskaliert. Weitere Informationen finden Sie in den Handbüchern der Coronis-Module.

Annexes et autres documents

  • WARNING :  Pour les anciens produits qui disposent d’une carte SIM avec un code PIN à 0000 , la mise à jour vers la version 4.07.02 sera fonctionelle.

    Second cas : Si la carte SIM avec un code PIN à 0000 est utilisée dans cette version (4.07.02), le passage vers une mise à jour antérieure est interdit.