Titan – AN48: Internal LoRa server

Looking for something else?

Scenario Details

MTX-StarLora is featured as LoRa-4G gateway using external LoRa Server. Check our app note 39.

MTX-StarLora is also featured with integrated Lora Server inside. That means that MTX-StarLora does not depend on external LoRa Servers, like TTN & among others, all the control over other gateways and external Lora devices is done internally. This is perfect to be independent of external parties.

MTX-StarLora it is integrated ChirpStack https://www.chirpstack.io/

Features:

  • End-devices Class A, B and C
  • Adaptative data-rate
  • Live frame-logging
  • Channel (re)configuration
  • Multi-tenant
  • APIs and integration
  • LoRaWAN 1.0 and 1.1 compatible

Description of the Example

This application note shows step by step how to create a LoRa network, with remote LoRa sensors connected and managed by internal LoRa server.

MTX-StarLora will use cellular LTE 4G as WAN interface, will collect all LoRa sensors information and will be sent to end-party cloud integration platform.

Chirpstack LoRa internal server will send LoRa sensor payload datas using HTTPS integration to Cervello platform.

Cervello cloud platform is perfect for this application because the VPI programming featureS as can receive and manage all payloads, filter, and decode this frame payload into telemetries values. Telemetries will be stored and can be displayed in visual tables, graphs…

Cervello will be also used a Device Manager: we can collect DNS information (IP address, time, IMEI, signal strength….) and can be used to group, and control using AT commands

LoRa sensors: we can recommend/tested following nodes:

  • Adeunis
  • RAK
  • URSALINK

Our new MTX-StarLora with Lora capabilities has also all MTX-StarLora-Titan features, so you still can use serial RS232/RS485/USB – Eth-4G gateways, Modbus, Datalogger, VPN, etc making one of the most industrial M2M-IoT featured complete router in the market.

width=910

Please check App note 49 if you want to extend the LoRa network with a slave gateway and have more deep technical aspect on LoRa Server implementation.

MTX-StarLora Configuration

First access to Titan using an Ethernet cable with the default 192.168.1.2 IP Address.

User: admin

Password: admin

width=610

Then, it is needed to configure MTX-StarLora with SIM card network APN information.

WAN -> Basic Setting

Please take care about “Sim PIN” (if SIM card is PIN enabled) and most important ones

“APN”, “Username” and “Password”.

Please keep filled Call Center field as showed, *99***1#

width=1149

 

Then click on “SAVE CONFIG” button and important, restart router using menu.

Other->Reboot to allow router restart with new configuration and connect to internet.

Check WAN IP and keep this value.

width=1113

In this example, LAN interface is used as it is connected directly to another Router with internet connection, will use 4G WAN as backup/failure.

Menu: Wan->Basic Setting->Utils.

Click on Failover config button and fill in your case the Gateway IP. If this fail, WAN will be switched to use 4G cellular network.

width=838

To configure LAN, MTX-StarLora has two Ethernet ports, using number one:

width=1079

To configure the DYNDNS, fill in the following fields:

width=1161

Server

Domain

Login

Password

Then, you can FOREVER even if IP public dynamic has been changed, to access TITAN.

width=1058

You can use other MTX-StarLora features as Serial Gateways, Modbus, Logger, MQTT, VPN, SMS…

LoRa Configuration

Please Enable Lora Server.

External Devices – LoRa Gateway it is not needed to use internal LoRa Server.

width=1071

Please fill Other->MQTT Broker to enable listening port 1883

width=1072

Then it is time to open Lora Server.

width=1074

New window will be opened with port 8080

Router address (normally 192.168.1.2:8080)

width=1119

My case http://starlora.ddns.net:8080

ChirpStack Server will be opened.

  • Default user: admin
  • Default password: admin

You can find information, guides, help and community forum at

https://www.chirpstack.io/

and

https://www.chirpstack.io/project/guides/connect-gateway/

ChirpStack Configuration Steps

It is mandatory to follow all this steps to create a Lora Network.

  • Step 1: Add a server
  • Step 2: Add/create a Gateway profile —- connected to 1) Server
  • Step 3: Add/create a Service profile — must be connected to 1) Server
  • Step 4: Add/create a Device profile – must be connected to 1) Server
  • Step 5: Add/create a Gateway – must be connected to 1) Server and 2) Gateway profile
  • Step 6: Add/create an Application — must be connected to 3) Service Profile
  • Step 7: Add Devices – must be connected to 4) Device Profile
  1. Repeat step 7 to add other external devices

Step 1: Adding a Server

Click on Network Server -> Add

Fill with a string in Network-server-name, example MTX-StarLora-JS-LORA. Fill with a string in Network-server server 127.0.0.1:8000.

width=1415

Fill Gateway Discovery as follow:

width=1418

Check if Network Server has been created:

width=1425

Step 2: Adding/Creating a Gateway Profile

Click on Gateway-profiles:

width=1644

And click on create:

width=1423

Fill some string name for the Gateway profile and use your Network Server created in step 1.

width=1441

Check if Gateway Profile is linked to Network Server.

width=1413

Step 3: Adding/Creating a Service Profile

Click on Service-profiles:

width=991

Fill with your Step 1 Network Server and Step 2 Service Profile names. Other fields please read Chirpstack documentation.

width=1411

As an example:

width=1433

Step 4: Adding/Creating a Device Profile

Click on Device-profiles:

width=983

And fill a name for Device-profile-name (mandatory)

Check your LoRaWan MAC version and other parameters as your LoRa scenario.

width=1440

If you want to add external devices using OTAA pls check JOIN fields. If you will use ABP keys leave this box unmarked.

width=1886

In this example, we will use default DEVEUI and Lora Keys stored in the nodes (some explanation in Step 7)

Fill CLASS-B and CLASS-C windows with YOUR specified LoRa scenario or adjust to your best performance features. This are some examples:

width=1889

width=1887

CODEC is a good ChirpStack feature. This is intented to get an object with extracted payload information and not all payload from the node.

If you are going to use just one type of same end LoRaWan sensors, you can ask your node manufacturer and fill/code. Read documentation/help. We will not use this feature in this application note.

width=1153

At the end of this application note you can see how we have CODEC code integrated in end IOT cloud Cervello.

Step 5: Adding/Creating a Gateway

This section may be not important but it is, we have to add and create the MTX-StarLora as a Gateway. Click on Gateways:

width=974

Then click on Create.

width=1851

And write some name on Gateway name and some Gateway description string.

Also fill some Gateway ID (Identification), as example 010203040a0b0c0d

In this example, Gateway name is JS-GATEWAY. Has also to use the Gateway-profile set as step 2.

width=1890

If successful you will get some live information:

width=1848

Step 6: Adding/Creating an Application

We are almost finishing, next point is creating a new Application. In this section we will also add the end LoRaWan nodes devices and see the payload.

Create an Application.

Click on Application -> Create

width=983

Fill Application name and Application description with some text strings and use Service Profile configured in step 3.

width=1888

As an example this is an application created.

width=1886

Step 7: Adding Devices

IMPORTANT POINT: Now we will create and add new end nodes LoRaWan devices.

width=1001

Take now the information of your LoRaWan device node.

You will need mandatory information:

  • DEVICE EUI (DEV EUI)
  • APPLICATION KEY (APP KEY)

You can get this information from your device provider, and sometimes, connecting the end remote device to your laptop.

HOW TO USE ADEUNIS END DEVICE

COMFORT ARF8275AAC

width=1594

Here you can extract DEV EUI

18B260000007AB

Introduce this data into Device description. Fill with 00 at the beginning just in case.

width=1928

Goto into Devices/MyDevice:

width=1885

width=1602

Copy the Lora App key.

width=1887

Keep Gen Application key in blank.

And then click on SET DEVICE KEYS.

width=1889

Wait till frames are received.

width=1844

width=1849

Click Device Data. Wait. Wait.

width=1531

You will find some join and up messages. Click on up and extract.

width=280

adr:true

dr:0

fCnt:323

fPort:1

data:TIAA5Sc=

objectJSON:

Read the manual and extract the information from this string.

Data is Base64 have to decode to HEX. Use

https://cryptii.com/pipes/base64-to-hex

4c 80 00 e5 27 -> 4c8000e527

You can use Adeunis manual but use https://codec-adeunis.com/decoder

{
  type: 0x4c Comfort data,
  status: {
    frameCounter: 4,
    hardwareError: false,
    lowBattery: false,
    configurationDone: false,
    configurationInconsistency: false
  },
  decodingInfo: values: [t=0, t-1, t-2, ...],
  temperature: {
    unit: °C,
    values: [
      22.9
    ]
  },
  humidity: {
    unit: %,
    values: [
      39
    ]
  }
}

Another example with Ursalink device. Connect AM100 to computer using USB cable and open ToolBox.

width=1805

In this software you can find Device EUI. Rembember this number is like IMEI, MAC… stored in the device and normally, can not be changed. In this case, we will use Application Key generated randomly by ChirpStark and we will copy it to Ursalink.

width=1658

width=1807

An important check on the device side is see if its Activaded.

width=1776

Check now again Devices traffic messages:

width=1516

Click on up message, and again similar information structure, information about network, LoRa and the data.

data:A2fUAARoSQZlIgAbAAYABWoAAA== ???

UC11: • data:AWfZAAJoPw==

Remote io home • data:CQEA

 

This sensor can read temperature, humidity and has a presence PIR. Adding more nodes will be like this:

width=1690

Keep in mind the LoRa frames, payloads are not getting out the ChirpStack server and/or be in Titan. Those are separate applications and we can not use any Titan information way (mqtt, http,,, etc). The only way to extract and send that information is, in Applications, use Integrations. Go to Applications>Integrations. You will find some integration with end cloud services:

HTTP

AWS SNS

AZURE

GCP

INFLUXDB

myDevices

SEMTECH

ThingBoards.io

We will use HTTP as maybe the easy way to POST all lora frame to a Server.

width=1886

Click on EDIT.

And fill the information.

In following example, we will use Cervello cloud platform to collect all the Lora payloads, decode and create simple Telemetries values.

Cervello collect information in a JSON payload (among other). Just adjust 2 headers and, the most important field is the URL.

In our case, we must fill in the URL the ID and password to connect properly to Cervello. You can also see we have created in Cervello a topic to receive these frames.

width=1890

HTTP Integration Using Cervello Stem

Create a NEW DEVICE (an already Organization created is needed, if not, create a new one).

Fill in name field some name, in our example, MTX-StarLora-STAR-LORA-TEST. Fill in Description some description, in our example, TEST LORA HTTP.

Device type: GATEWAY

Communication Protocol: DEFAULT

And Connectivity Media: Other

Then, Device Credentials are created.

Please keep attention. Click on Device Credentials.Then a box appears with

  • CLIENT ID
  • ACCESS KEY
  • ACCESS TOKEN

width=660

Copy them in some document as Access Token will not appear anymore. In our case,

width=1843

We have:

  • Client ID: jtbqr5gtypev9u
  • Access key: apm87w1pcysqaw
  • Access tocken: du79dfe4qk8ptj

The URL in ChripStack is then:

https://broker.release.cervello.io?c=jtbqr5gtypev9u&u=apm87w1pcysqaw&p=du79dfe4qk8ptj&t=/lora/debug

In Cervello we will use VPI programming interface with the following steps:

  • Create an application (our example AppStarLora)
  • Link device to application

Create a VPI, in our case VPI-StarLora name.

Add following block:

Device Data Listener and write a name to Topic, in our example, lora/debug

width=1739

On debug you can see some live LoRa packet, this case is an Adeunis end node.

{
  organizationId: 1973cbd9-75a2-4599-aa90-6bae7f37a204,
  originatorId: b89dd4ed-9297-424b-8e18-020df9662c5d,
  deviceId: b89dd4ed-9297-424b-8e18-020df9662c5d,
  deviceName: MTX-StarLora-STAR-LORA-TEST,
  referenceName: null,
  applications: [
    82e3c562-48eb-4223-9056-21449b44f684
  ],
  assets: [],
  tags: [],
  customFields: null,
  isPublic: false,
  clientId: jtbqr5gtypev9u,
  topic: /lora/debug,
  payload: {
    applicationID: 1,
    applicationName: JS-APP,
    deviceName: COMFORT,
    devEUI: ABiyYAAAB6s=,
    rxInfo: [
      {
        gatewayID: AQIDBAoLDA0=,
        time: null,
        timeSinceGPSEpoch: null,
        rssi: -47,
        loRaSNR: 10.5,
        channel: 4,
        rfChain: 0,
        board: 0,
        antenna: 0,
        location: {
          latitude: 40.39924,
          longitude: -3.71709,
          altitude: 609,
          source: UNKNOWN,
          accuracy: 0
        },
        fineTimestampType: NONE,
        context: dUmrDA==,
        uplinkID: lhkyE2YbTg2sHkKG7C0krw==,
        crcStatus: CRC_OK
      }
    ],
    txInfo: {
      frequency: 867300000,
      modulation: LORA,
      loRaModulationInfo: {
        bandwidth: 125,
        spreadingFactor: 12,
        codeRate: 4/5,
        polarizationInversion: false
      }
    },
   adr: true,
    dr: 0,
    fCnt: 416,
    fPort: 1,
    data: TCAA5Cg=,
    objectJSON: ,
    tags: {},
    confirmedUplink: true,
    devAddr: BaQxnw==
  },
  time: 1612525208425,
  action: message_publish

This other is the URSALINK AM100.

{
  organizationId: 1973cbd9-75a2-4599-aa90-6bae7f37a204,
  originatorId: b89dd4ed-9297-424b-8e18-020df9662c5d,
  deviceId: b89dd4ed-9297-424b-8e18-020df9662c5d,
  deviceName: MTX-StarLora-STAR-LORA-TEST,
  referenceName: null,
  applications: [
    82e3c562-48eb-4223-9056-21449b44f684
  ],
  assets: [],
  tags: [],
  customFields: null,
  isPublic: false,
  clientId: jtbqr5gtypev9u,
  topic: /lora/debug,
  payload: {
    applicationID: 1,
    applicationName: JS-APP,
    deviceName: AM100,
    devEUI: JOEkEnohcgA=,
    rxInfo: [
      {
        gatewayID: AQIDBAoLDA0=,
        time: null,
        timeSinceGPSEpoch: null,
        rssi: -40,
        loRaSNR: 12.8,
        channel: 4,
        rfChain: 0,
        board: 0,
        antenna: 0,
        location: {
          latitude: 40.39924,
          longitude: -3.71709,
          altitude: 609,
          source: UNKNOWN,
          accuracy: 0
        },
        fineTimestampType: NONE,
        context: fhjurA==,
        uplinkID: q9xQmrwcQSadGQo+iSI2Tw==,
        crcStatus: CRC_OK
}
    ],
    txInfo: {
      frequency: 867300000,
      modulation: LORA,
      loRaModulationInfo: {
        bandwidth: 125,
        spreadingFactor: 10,
        codeRate: 4/5,
        polarizationInversion: false
      }
    },
    adr: true,
    dr: 2,
    fCnt: 3,
    fPort: 85,
    data: AXVkA2f1AARoUQZlFAAaAAkABWoAAANn9QAEaE8GZRQAGgAJAAVqAAA=,
    objectJSON: ,
    tags: {},
    confirmedUplink: true,
    devAddr: BfRdnw==
  },
  time: 1612525356533,
  action: message_publish
}

Our task now is filter the frames using ID, in our Switch block.

width=1326

width=1271

Function block is to decode the frame information. Ask your LoRaWan end device to get some information and example code. It is usually named CODEC.

/**
 * Ursalink AM100 / AM102 Payload Decoder
 *
 * definition [channel-id] [channel-type] [channel-data]
 *
 * 01: battery      -> 0x01 0x75 [1byte]  Unit: %
 * 03: temperature  -> 0x03 0x67 [2bytes] Unit: °C
 * 04: humidity     -> 0x04 0x68 [1byte]  Unit: %
 * 05: PIR          -> 0x05 0x6A [2bytes] 
 * 06: illumination -> 0x06 0x65 [6bytes] Unit: lux
 * ------------------------------------------ AM100
 * 07: CO2          -> 0x07 0x7D [2bytes] Unit: ppm
 * 08: TVOC         -> 0x08 0x7D [2bytes] Unit: ppb
 * 09: Pressure     -> 0x09 0x73 [2bytes] Unit: hPa
 * ------------------------------------------ AM102
 */
function Decoder(bytes) {
    var decoded = {};

    for (var i = 0; i < bytes.length;) {
        var channel_id = bytes[i++];
        var channel_type = bytes[i++];
        // BATTERY
        if (channel_id === 0x01 && channel_type === 0x75) {
            decoded.battery = bytes[i];
            i += 1;
        }
        // TEMPERATURE
        else if (channel_id === 0x03 && channel_type === 0x67) {
            decoded.temperature = readInt16LE(bytes.slice(i, i + 2)) / 10;
            i += 2;
        }
        // HUMIDITY
        else if (channel_id === 0x04 && channel_type === 0x68) {
            decoded.humidity = bytes[i] / 2;
            i += 1;
        }
        // PIR
        else if (channel_id === 0x05 && channel_type === 0x6A) {
            decoded.activity = readInt16LE(bytes.slice(i, i + 2));
            i += 2;
        }
        // LIGHT
        else if (channel_id === 0x06 && channel_type === 0x65) {
            decoded.illumination = readInt16LE(bytes.slice(i, i+2));
           // decoded.infrared_and_visible = readInt16LE(bytes.slice(i + 2, i + 4));
           // decoded.infrared = readInt16LE(bytes.slice(i + 4, i + 6));
            i += 6;
        }
        // CO2
        else if (channel_id === 0x07 && channel_type === 0x7D) {
            decoded.co2 = readInt16LE(bytes.slice(i, i + 2));
            i += 2;
        }
        // TVOC
        else if (channel_id === 0x08 && channel_type === 0x7D) {
            decoded.tvoc = readInt16LE(bytes.slice(i, i + 2));
            i += 2;
        }
        // PRESSURE
        else if (channel_id === 0x09 && channel_type === 0x73) {
            decoded.pressure = readInt16LE(bytes.slice(i, i + 2))/10;
            i += 2;
        } else {
            break;
        }
    }
    return decoded;
}

/* ******************************************
 * bytes to number
 ********************************************/
function readUInt16LE(bytes) {
    var value = (bytes[1] << 8) + bytes[0]; return value & 0xffff; } function readInt16LE(bytes) { var ref = readUInt16LE(bytes); return ref > 0x7fff ? ref - 0x10000 : ref;
}

/* ******************************************
 * payload processing
 ********************************************/

var hexBase64Payload = data.payload.data;

var hexPayload = Buffer.from(hexBase64Payload,\'base64\');
var decodedPayload = Decoder(Buffer.from(hexPayload,\'hex\'));


var msg = {
    device_name: data.payload.deviceName,
    deviceId: data.deviceId,
    data: {}
}

msg[data][data.payload.deviceName] = {
           data: decodedPayload }
    

send(0, msg);

Almost finished. In VPI, telemetry block create one TELEMETRY, in our example, will take just TEMP as a Telemetry value.

width=1149

In this example, we have created a peripheral device which will allow separate telemetries and information from other nodes. This way will also do easy to create groups, tags, for a better end user experience.

Clink on AM100 peripheral device in Device Manager and get all information.

width=1845

Une question ? Besoin d’un devis ? Contactez-nous.

  • Ce champ n’est utilisé qu’à des fins de validation et devrait rester inchangé.

Annexes et autres documents

Annexes et autres documents

Annexes et autres documents

Annexes et autres documents

Annexes et autres documents

Annexes et autres documents

Annexes et autres documents

FAQ

Non, le concentrateur n’est pas capable de déchiffrer les données des équipements WM-BUS car il n’embarque pas de coffre-fort afin de garantir la sécurité des clés de chiffrage de vos équipements. Les données récupérées sont déposées sans modification (sans déchiffrage) par le concentrateur sur votre serveur distant.

Veuillez vérifier ces points dans cet ordre :

  • le niveau de la pile : si la pile est trop basse ou vide, le produit ne fonctionnera pas correctement ou plus du tout.
  • Le niveau de réception du modem : un mauvais signal au niveau du modem peut également empêcher le concentrateur de déposer les fichiers. Voir pour déplacer le produit ou installer une antenne externe pour améliorer la qualité du signal.
  • Le dernier fichier de configuration : un mauvais fichier de configuration peut bloquer le produit.

À distance, en vérifiant les fichiers déposés périodiquement si la configuration du produit a bien été faite.

À proximité, en passant l’aimant sur le haut du produit, vous entendrez 3 bips courts retentir.

Remplacer le produit et injecter la configuration de l’ancien produit dans le nouveau. Si une liste blanche est utilisée, ne pas oublier de l’injecter dans le nouveau produit également.

Annexes et autres documents

Autres manuels

Notes d'Application

FAQ

CONFIGURATION DE LA PASSERELLE

Commencer par vérifier que les paramètres IP de l’ordinateur sont compatibles avec l’adresse IP de la WebdynSunPM (par défaut 192.168.1.12) Lancer un navigateur Web (Chrome, Firefox, Edge, Safari, …) et saisir l’adresse IP du concentrateur WebdynSunPM dans la barre d’adresse. Une page d’authentification va s’afficher : Les accès par défaut sont :
Identifiant Mot de passe
userhigh high
Cliquer sur « Login »
Il existe deux solutions de configuration, via l’interface web et via SMS :
  • Configuration via l’interface web :
Etablir tout d’abord une connexion au concentrateur en se connectant dessus pour accéder à la configuration des serveurs : Saisir le mode de connexion « Ethernet » ou « modem » : Dans le cas d’une configuration par Ethernet, veiller à ce que les paramètres IP soient compatibles avec l’accès au serveur d’après la configuration du réseau local du concentrateur. Dans le cas d’une connexion par Ethernet, la configuration doit être compatible avec la topologie du réseau local du concentrateur afin qu’il puisse accéder aux serveurs. Cette configuration se fait via la page de configuration « Networks » (voir chapitre 3.2.2.3 : « Réseaux (Networks) »). Dans le cas d’une connexion par modem, la configuration du modem doit être correcte avant de pouvoir effectuer une connexion. Cette configuration se fait dans la page de configuration « Modem » (voir chapitre 3.2.2.4 : « Modem »). Les paramètres des serveurs à configurer au minimum sont les suivants : Il faut donc configurer les champs : « Interface », « Type », « Server type », « Address », « Port », « Login » et « Password ». Les autres champs peuvent être laissés aux valeurs par défaut à condition que les répertoires aient été créés correctement auparavant. Voir chapitre 3.1.2 : « Fichiers de configuration » pour plus de détails.
  • Configuration par SMS :
La configuration par SMS nécessite l’envoi des commandes suivantes :
      • Apn: pour configurer l’APN de la carte SIM. (voir chapitre 4.2 : « Commande de configuration du modem « apn »)
      • Ftp: pour configuration le serveur FTP qui va contenir la configuration du concentrateur (voir chapitre 4.3 : « Commande de configuration du FTP « ftp » »).
      • Connect : pour lancer la connexion au serveur FTP et charger la configuration (voir chapitre 4.1: « Commande de connexion « connect » 

L’accès au serveur FTP dépend de la solution adoptée.

Si vous avez choisi un portail, les identifiants d’accès au serveur FTP vous est communiqué par celui-ci.

Si vous voulez utiliser votre propre serveur FTP, veuillez vous rapprocher de votre administrateur réseau.

Pour toutes autres configurations et pour déterminer la solution qui convient le mieux, il faut se rapprocher du service commercial Webdyn qui saura conseiller et rediriger vers les interlocuteurs pertinents : contact@webdyn.com

UTILISATION GENERALE DE LA PASSERELLE

Il existe 2 méthodes pour forcer un retour aux paramètres usine du concentrateur :
  • Appuyer sur le bouton Retour Usine du concentrateur pendant 20 secondes :
Attendre. Le concentrateur va redémarrer avec sa configuration usine.
  • Si une carte SIM est installée et configurée, un SMS « factory » permet également d’effectuer un retour usine. Il suffit d’envoyer le SMS « factory » au numéro de téléphone de la carte SIM (voir chapitre 4.7: « Commande de retour usine « factory » »)

Il est possible d’envoyer des commandes aux équipements connectés si celui-ci les accepte.

La WebdynSunPM mémorise jusqu’à 50Mo de données non compressées par équipement déclaré.

En cas de non-accès au serveur distant, le concentrateur WebdynSunPM peut donc stocker les données pendant plusieurs mois.

Le temps maximum de stockage de données varie en fonction du nombre de données à collecter et de la fréquence de la collecte configurée.

La durée moyenne de sauvegarde varie entre 3 et 4 mois.

La durée de vie moyenne de la batterie est de 5 ans.

Elle peut varier selon l’environnement de l’installation.

Tous nos produits sont garantis 2 ans.

Pour plus d’information, consultez nos conditions générales de vente.

Le volume de données dépend des fichiers échangés.

La moyenne est de l’ordre de 5 Mo par mois et varie pour chaque installation.

COMPATIBILITE DES ONDULATEURS

Voir chapitre 1.4 : « Équipements supportés ».

Compatibilité des équipements modbus :

  • Vérifier qu’il possède une sortie TIC
  • Utiliser une paire torsadée blindée pour le câblage
  • Vérifier que la sortie TIC est activée sur le compteur
  • Pour les compteurs PME/PMI, vérifier la vitesse du flux TIC et la polarisation
  • Compteur « Bleu » électronique monophasé multi tarifs (CBEMM)
  • Compteur « Bleu » électronique monophasé multi tarifs (CBEMM – évolution ICC)
  • Compteur « Bleu » électronique triphasé multi tarifs (CBETM)
  • Compteur « Jaune » électronique (CJE)
  • Compteur « Interface Clientèle Emeraude » (ICE)
  • Compteur « Interface Clientèle Emeraude à quatre quadrants » (ICE-4Q)
  • Compteur « Saphir »
  • Compteur « PME-PMI »
  • Compteur « Linky »

Annexes et autres documents

  • Liste des onduleurs compatibles avec la WebdynSun
  • Annexes des onduleurs
  • Supervision équipement Modbus
  • 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.

FAQ

CONFIGURATION DE LA PASSERELLE WEBDYNSUN

  • Commencez par vérifier que les paramètres IP de votre ordinateur sont compatibles avec l’adresse « IP » de la WebdynSun (par défaut : 192.168.1.12). 
  • Puis lancez un navigateur Web (Firefox ou IE) et saisissiez l’adresse IP de la WebdynSun dans la barre d’adresse. Une page d’authentification va s’afficher : 

 Les accès par défaut sont :
Nom d’utilisateur : userhigh
Mot de passe : high 

  • Cliquez sur « se connecter »  

Il existe deux types de configuration, via l’interface web et via SMS.

Configuration via l’interface web :

1/ Accédez à la page de configuration avec l’adresse IP du concentrateur (par défaut 192.168.1.12)

2/ Allez dans l’onglet Configuration.

3/ Sélectionnez le mode de connexion Ethernet ou modem :

Dans le cas d’une connexion via le réseau local (Ethernet) :

  • Editez les paramètres IP de la WebdynSun en lui attribuant une adresse compatible avec le réseau.

Attention, tous les champs doivent être renseignés d’après la configuration de votre réseau local.

Dans le cas d’une connexion via le réseau GPRS (Modem) :

  • Modifiez les paramètres de connexion du modem GPRS, en se basant sur les paramètres fournis par votre opérateur mobile.

4/ Editez les paramètres du serveur FTP.

5/ Valider les modifications.

6/ Redémarrez la passerelle WebdynSun afin que les nouveaux paramètres soient pris en compte.

7/ Dans le menu, cliquez sur l’onglet « installation », puis le sous-onglet « connexion » et lancez la connexion.

Configuration via SMS :

Ce mode de configuration nécessite l’utilisation d’une carte SIM active avec une option data et un code PIN qui doit être, soit « 0000 », soit désactivé.
La carte SIM doit être insérée dans le boitier avant la mise sous tension du produit.
Après la mise sous tension du produit envoyez les SMS suivants au numéro de la carte SIM précédemment insérée :

SMS de configuration de l’APN :
Après remplacement des champs génériques par ceux de votre opérateur, envoyez le SMS* suivant :
apn=apn_name;usr=user_name;pwd=password;

Remplacez les champs du SMS ci-dessus avec les informations suivantes :

  • apn_name : Nom de l’APN fourni par votre opérateur mobile
  • user_name : Identifiant APN fourni par votre opérateur mobile
  • password : Mot de passe APN fourni par votre opérateur mobile

SMS pour la configuration FTP :
Après remplacement des champs génériques par ceux de votre serveur FTP, envoyez le SMS* suivant :

Ftp=server_name:user_name:password:port;

Remplacez les champs du SMS ci-dessus avec les informations suivantes :

  • server_name : Adresse du serveur FTP
  • user_name : Identifiant du compte FTP
  • Password : Mot de passe du compte FTP
  • Port : Port du serveur FTP (par défaut port 21)

SMS de connexion :

Envoyez par SMS* le mot « connect » pour lancer une connexion au serveur FTP

*Attention : la mise en forme du SMS doit être strictement identique à celle-ci-dessus (ex : pas d’espace entre les caractères, …)

 UTILISATION GÉNÉRALE DE LA PASSERELLE WEBDYNSUN

Il existe 2 méthodes pour reseter la passerelle.

Si le mode de connexion est en Ethernet :

  • Débranchez le secteur
  • Enlevez le couvercle
  • Débranchez la batterie
  • Mettez le dip Switch 2 présent sur la carte de la WebdynSun en position « ON »
  • Démarrez la WebdynSun en la branchant seulement sur secteur
  • Attendre que toutes les leds clignotent puis s’arrêtent de clignoter (3 à 5 min).
  • Débranchez le secteur
  • Remettez le dip Switch 2 sur « OFF»
  • Rebranchez la batterie
  • Rebranchez le Secteur, la WebdynSun démarre normalement.

S’il y a une carte SIM insérée dans le concentrateur :

  • Envoyer un SMS contenant le mot « factory » au numéro de la carte SIM insérée.

N.B. : Le reset de la passerelle restaure la configuration à son état d’origine. Attention, les données seront conservées mais pas les paramétrages spécifiques. Il faut donc configurer à nouveau tous les paramètres.

Il est possible d’envoyer des commandes aux équipements connectés sauf à certains onduleurs ou esclaves Modbus qui n’acceptent pas les requêtes d’écriture.

Pour les équipements qui le permettent, il est possible de créer des fichiers de commande sur le serveur FTP.

La capacité de la mémoire de la WebdynSun est d’environ 100Mo.
En cas de non accès au serveur distant, le concentrateur WebdynSun peut donc stocker les données pendant plusieurs mois.

Le temps maximum de stockage de données varie en fonction du nombre de données à collecter.

La durée moyenne de sauvegarde varie entre 3 et 4 mois.

La durée de vie moyenne de la batterie est de 5 ans.

Elle peut varier selon l’environnement de l’installation.

Oui on peut envoyer des données sur un automate si ce dernier intègre le protocole Modbus.

Le fichier de configuration « Report » permet au concentrateur WebdynSun d’écrire automatiquement les valeurs lues sur un esclave Modbus.

Tous nos produits sont garantis 2 ans.

Pour plus d’information, consultez nos conditions générales de vente.

Les fichiers déposés par la passerelle WebdynSun sont compressés en format Gz.

Les données contenues dans ces fichiers sont structurées au format csv.

Le volume de données dépend des fichiers échangés.

La moyenne est de l’ordre de 5 Mo par mois et varie pour chaque installation.

 COMPATIBILITÉ DES ONDULEURS AVEC LA PASSERELLE WEBDYNSUN

Il est possible de connecter des onduleurs de différentes marques sur le port RS485(B) ou via le port Ethernet si le protocole des onduleurs est basé sur le protocole Modbus (RTU ou TCP).

Toutefois, il n’est pas possible de connecter des onduleurs de marques différentes sur le même port RS485(A).

Pour connaitre la liste des onduleurs compatibles, référez-vous à la page produit de la passerelle de données WebdynSun.

  • Vérifiez si le bon protocole onduleur est sélectionné avant de lancer la détection :

  • Vérifiez le câblage et la configuration des onduleurs en se basant sur les annexes onduleurs.
  • Vérifiez que les onduleurs ne soient pas en mode OFF ou stand-by.
  • Vérifiez que les bouchons de fin de lignes sur le Bus RS 485(A) soient activés.

COMPATIBILITÉ AVEC LES ÉQUIPEMENTS MODBUS

Oui, il faut configurer l’équipement à connecter et créer son fichier de définition Modbus.

La configuration est principalement basée sur les paramètres série de bus RS485 ou les paramètres IP.

Oui, il est possible de connecter différents équipements Modbus sur le même port RS485 (B).

Toutefois, pour qu’ils puissent communiquer ensemble, ils doivent avoir les mêmes paramètres de communication (paramètres de bus ou paramètres IP compatibles).

COMPATIBILITÉ AVEC LES COMPTEURS TIC

  • Vérifiez qu’il possède une sortie TIC
  • Utilisez une paire torsadée blindée pour le câblage
  • Vérifiez que la sortie TIC est activée sur le compteur
  • Pour les compteurs PME/PMI, vérifiez la vitesse du flux TIC
  • Pour les compteurs Landis+Gyr L18C5, vérifiez que le flux TIC sortant est cohérent
  • Pour les compteurs Schlumberger tarif jaune, ajoutez une résistance entre 200 et 300 Ohms entre les bornes de l’entée TIC et la WebdynSun.
  • Compteur « Bleu » électronique monophasé multitarifs (CBEMM)
  • Compteur « Bleu » électronique monophasé multitarifs (CBEMM – évolution ICC)
  • Compteur « Bleu » électronique triphasé multitarifs (CBETM)
  • Compteur « Jaune » électronique (CJE)
  • Compteur « Interface Clientèle Emeraude » (ICE)
  • Compteur « Interface Clientèle Emeraude à quatre quadrants » (ICE-4Q)
  • Compteur « PME-PMI»

Annexes et autres documents

  • Warning – Firmware – mise à jour V4.07.02 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 fonctionnelle. 
    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. 

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. 

Annexes et autres documents

FAQ

Annexes et autres documents

FAQ

Annexes et autres documents

FAQ

Annexes et autres documents

FAQ

CONFIGURATION DE LA GATEWAY WEBDYNRF

  • Dans le cas où le fichier est supprimé du répertoire après connexion du concentrateur WebdynRF, le problème est généralement dû à une erreur du format de fichier. Les fichiers de configuration et de commande doivent respecter le format décrit dans les fichiers schéma (XSD).
    Pour vérifier la cohérence d’un schéma, ouvrez le fichier XML avec l’éditeur de texte Notepad++ et installez le complément « XML Tool ». Copiez ensuite le fichier XSD correspondant au fichier XML dans le même répertoire, et sélectionnez dans XML Tool « Validate now ». Les erreurs détectées par l’outil doivent s’afficher.
  • Dans le cas où le fichier n’est pas supprimé du serveur, le problème le plus courant est que le fichier n’a pas été déposé au bon endroit. Le fichier doit être disponible sur le serveur dans le répertoire « INBOX », et dans le sous-répertoire ayant pour nom l’uid du produit (exemple « /INBOX/0045CE/ »).

 UTILISATION GÉNÉRALE DE LA GATEWAY WEBDYNRF

La quantité de données échangées sur le réseau GPRS varie en fonction de la configuration. Cependant, on peut estimer une consommation de l’ordre de 5Mo / mois.

Le concentrateur WebdynRF consomme en moyenne environ 250mA.

Il existe 2 modes de mise à jour de firmware :
La mise à jour locale :
Sur l’interface de configuration de la WebdynRF, accédez à l’onglet « Actions », et sélectionnez l’updater dans le menu « File upload » avant de cliquer sur le bouton « Upload »

La mise à jour à distance :
Téléchargez le serveur FTP le fichier contenant l’updater (fichier avec l’extension « .bz2 ») dans le répertoire « BIN ». Puis déposez la commande de mise à jour dans le répertoire INBOX correspondant à votre concentrateur (« INBOX/« , avec , l’identifiant du concentrateur concerné)

La commande de mise à jour doit respecter le format suivant:

      updater.tar.bz2
      checksum_md5

updater.tar.bz2
checksum_md5

Avec :

  • updater.tar.bz2 : Nom du fichier updater téléchargé dans le répertoire « BIN »
  • checksum_md5 : Code md5 du fichier updater

Une absence de connexion au serveur FTP peut s’expliquer par un problème de connexion au réseau (Ethernet ou GPRS), par un problème d’ouverture de session FTP ou par un non déclenchement de la connexion.

En cas de problème de connexion au réseau, vérifiez les points suivants:

  • Ethernet :
    • Mode du modem à « off » ou « alwaysoff »
    • Champs « Gateway » correctement saisi
    • Au moins un serveur DNS doit être configuré
  • GPRS :
    • Mode du modem à « on »
    • APN, identifiant APN et mot de passe APN correctement saisis
    • Numéro d’appel GPRS à « *99***1# »

En cas de problème d’ouverture de session, vérifiez les points suivants:

  • Paramètres FTP incorrects
  • Port TCP 21 fermé en sortie
  • Problème de résolution du nom de domaine: le serveur DNS n’est pas précisé

En cas de non déclenchement de la connexion :

Dans ce cas, seule la connexion automatique ne fonctionne pas. Le problème est généralement dû à une mauvaise configuration des schedules. Attention, l’ID des schedules doit être un entier.

 UTILISATION PARTICULIÈRE DE LA PASSERELLE WEBDYNRF WIRELESS M-BUS

Pour que les données des modules WM-bus soient remontées, il faut :

  • Choisir le mode correspondant aux modules utilisés (S, T ou N)
  • Définir les modules ou groupes de modules à traiter

Un module peut être défini de manière unique par l’ensemble des champs ci-dessous :

  • Id
  • Manufacturer
  • Version
  • Medium

Dans le cas où les données d’un module seraient cryptées, il est possible de définir la clé de cryptage de ce module dans le champ « Key ».

Afin de simplifier la saisie des modules à traiter, il possible de définir un groupe de module respectant les champs saisis. Les autres champs seront alors laissés vides (ci-dessous un exemple de configuration permettant de récupérer l’ensemble des modules du manufacturer Webdyn (WDN) avec pour clé de cryptage « 00000000000000000000000000000000 ».

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

Remarque : Pour que les modules (filtres) saisis soient pris en compte, le mode « ByPass filter » doit être désactivé.

UTILISATION PARTICULIÈRE DE LA WEBDYNRF WAVENIS

La connexion de l’outil au concentrateur est réalisée via l’accès installateur (install).

Il faut donc utiliser le mot de passe installateur (par défaut « middle »), et non celui de l’administrateur (par défaut « high »)

Les statuts remontés par le concentrateur WebdynRF sont les valeurs brutes contenues dans les modules Wavenis. Elles sont remontées sans interprétation. Pour plus de détails, se référer aux manuels des modules Coronis.

Annexes et autres documents

FAQ

CONFIGURATION DE LA GATEWAY WEBDYNRF

  • Dans le cas où le fichier est supprimé du répertoire après connexion du concentrateur WebdynRF, le problème est généralement dû à une erreur du format de fichier. Les fichiers de configuration et de commande doivent respecter le format décrit dans les fichiers schéma (XSD).
    Pour vérifier la cohérence d’un schéma, ouvrez le fichier XML avec l’éditeur de texte Notepad++ et installez le complément « XML Tool ». Copiez ensuite le fichier XSD correspondant au fichier XML dans le même répertoire, et sélectionnez dans XML Tool « Validate now ». Les erreurs détectées par l’outil doivent s’afficher.
  • Dans le cas où le fichier n’est pas supprimé du serveur, le problème le plus courant est que le fichier n’a pas été déposé au bon endroit. Le fichier doit être disponible sur le serveur dans le répertoire « INBOX », et dans le sous-répertoire ayant pour nom l’uid du produit (exemple « /INBOX/0045CE/ »).

 UTILISATION GÉNÉRALE DE LA GATEWAY WEBDYNRF

La quantité de données échangées sur le réseau GPRS varie en fonction de la configuration. Cependant, on peut estimer une consommation de l’ordre de 5Mo / mois.

Le concentrateur WebdynRF consomme en moyenne environ 250mA.

Il existe 2 modes de mise à jour de firmware :
La mise à jour locale :
Sur l’interface de configuration de la WebdynRF, accédez à l’onglet « Actions », et sélectionnez l’updater dans le menu « File upload » avant de cliquer sur le bouton « Upload »

La mise à jour à distance :
Téléchargez le serveur FTP le fichier contenant l’updater (fichier avec l’extension « .bz2 ») dans le répertoire « BIN ». Puis déposez la commande de mise à jour dans le répertoire INBOX correspondant à votre concentrateur (« INBOX/« , avec , l’identifiant du concentrateur concerné)

La commande de mise à jour doit respecter le format suivant:

      updater.tar.bz2
      checksum_md5

updater.tar.bz2
checksum_md5

Avec :

  • updater.tar.bz2 : Nom du fichier updater téléchargé dans le répertoire « BIN »
  • checksum_md5 : Code md5 du fichier updater

Une absence de connexion au serveur FTP peut s’expliquer par un problème de connexion au réseau (Ethernet ou GPRS), par un problème d’ouverture de session FTP ou par un non déclenchement de la connexion.

En cas de problème de connexion au réseau, vérifiez les points suivants:

  • Ethernet :
    • Mode du modem à « off » ou « alwaysoff »
    • Champs « Gateway » correctement saisi
    • Au moins un serveur DNS doit être configuré
  • GPRS :
    • Mode du modem à « on »
    • APN, identifiant APN et mot de passe APN correctement saisis
    • Numéro d’appel GPRS à « *99***1# »

En cas de problème d’ouverture de session, vérifiez les points suivants:

  • Paramètres FTP incorrects
  • Port TCP 21 fermé en sortie
  • Problème de résolution du nom de domaine: le serveur DNS n’est pas précisé

En cas de non déclenchement de la connexion :

Dans ce cas, seule la connexion automatique ne fonctionne pas. Le problème est généralement dû à une mauvaise configuration des schedules. Attention, l’ID des schedules doit être un entier.

 UTILISATION PARTICULIÈRE DE LA PASSERELLE WEBDYNRF WIRELESS M-BUS

Pour que les données des modules WM-bus soient remontées, il faut :

  • Choisir le mode correspondant aux modules utilisés (S, T ou N)
  • Définir les modules ou groupes de modules à traiter

Un module peut être défini de manière unique par l’ensemble des champs ci-dessous :

  • Id
  • Manufacturer
  • Version
  • Medium

Dans le cas où les données d’un module seraient cryptées, il est possible de définir la clé de cryptage de ce module dans le champ « Key ».

Afin de simplifier la saisie des modules à traiter, il possible de définir un groupe de module respectant les champs saisis. Les autres champs seront alors laissés vides (ci-dessous un exemple de configuration permettant de récupérer l’ensemble des modules du manufacturer Webdyn (WDN) avec pour clé de cryptage « 00000000000000000000000000000000 ».

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

Remarque : Pour que les modules (filtres) saisis soient pris en compte, le mode « ByPass filter » doit être désactivé.

UTILISATION PARTICULIÈRE DE LA WEBDYNRF WAVENIS

La connexion de l’outil au concentrateur est réalisée via l’accès installateur (install).

Il faut donc utiliser le mot de passe installateur (par défaut « middle »), et non celui de l’administrateur (par défaut « high »)

Les statuts remontés par le concentrateur WebdynRF sont les valeurs brutes contenues dans les modules Wavenis. Elles sont remontées sans interprétation. Pour plus de détails, se référer aux manuels des modules Coronis.

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.