Status

Date

Doc Version

Doc Number

Applicable

Confidentiality

RELEASED

v1.1A

WP-RM-133

WNT Client v3; Backend v3; Linux gateway 1.3.0

PUBLIC


Introduction

This document describes the minimum test for testing connection between WNT and a gateway compatible with WP-RM-128 [1]. A WP-RM-128 compatible gateway implementation is provided for users in https://github.com/wirepas/gateway.

Prerequisites

For running the tests it is required that tester has access to the WNT client and SSH access to the WNT backend. As MQTT broker's storage is deleted during the tests, it is recommended that the tests are run in dedicated testing backend.
 All commands in the tests are run in WNT backend's ~/wnt folder, unless otherwise stated.

Single sink test cases

These test cases are run with single gateway that has single sink. The sink should have valid configuration.

gw-event/status topic

Retained flag

The test verifies that gw-event/status topic is retained.

  • Shut down the gateway
  • Stop the WNT services
docker-compose down
  • Delete MQTT broker's storage

WNT 1.7 / 2.0

docker volume rm wnt_mosquittodb

WNT 3.0

docker volume rm wnt_vernemq_data
  • Start the WNT services and print the log
docker-compose up -d; docker-compose logs -ft
  • Start the gateway
  • Verify that sink can be seen from gateway_communicator's prints
  • Checking for removed pseudo ids
  • ========== PSEUDO ID TO SINK START ==========
  • Sink: <gateway_id>/sink<sink_id> (<network_id>:<node_id>) -
  • =========== PSEUDO ID TO SINK END =====================
  • NETWORK ID TO SINK LIST START ==========Network id: <network_id>
  • Sink: <gateway_id>/sink<sink_id> (<network_id>:<node_id>) -
=========== NETWORK ID TO SINK LIST END ===========
  • Restart the parser and print the log
docker restart wnt_parser; docker-compose logs -ft
  • Verify that parser prints information about the gateway. Please note that it can take up to 30 seconds before this message is written to the log.

WNT 1.7

Handling gateway status event message
Gateway status message from: <gateway_id> state: 1

WNT 2.0 / 3.0

Handling gateway status event message
Gateway online: <gateway_id>

Last will

The test verifies that MQTT last will is set correctly and gateway status is set as offline when it is shut down.

  • Shut down the gateway
  • Stop the WNT services
docker-compose down
  • Delete MQTT broker's storage

WNT 1.7 / 2.0

docker volume rm wnt_mosquittodb

WNT 3.0

docker volume rm wnt_vernemq_data
  • Start the WNT services and print the log
docker-compose up -d; docker-compose logs -ft
  • Start the gateway
  • Verify that sink can be seen from gateway_communicator's prints
Checking for removed pseudo ids
========== PSEUDO ID TO SINK START ==========
Sink: <gateway_id>/sink<sink_id> (<network_id>:<node_id>) -
=========== PSEUDO ID TO SINK END ===========
========== NETWORK ID TO SINK LIST START ==========
Network id: <network_id>
Sink: <gateway_id>/sink<sink_id> (<network_id>:<node_id>) -
=========== NETWORK ID TO SINK LIST END ===========
  • Shut down the gateway so that MQTT disconnection is not called in the gateway
    • Usually this can be done by disconnecting the gateway's network connection
    • Please note that it is required that last will message is sent manually if MQTT disconnect is called in the gateway code
  • Verify that parser notices that gateway was shut down. Please not that it can take up to 30 seconds before this message is written to the log.

WNT 1.7

Handling gateway status event message
Gateway status message from: <gateway_id> state: 2

WNT 2.0 / 3.0

Handling gateway status event message
Gateway offline: <gateway_id>
  • Restart the WNT services
docker-compose down; docker-compose up -d; docker-compose logs -ft 
  • Verify that parser prints information about the gateway

WNT 1.7

Handling gateway status event message
Gateway status message from: <gateway_id> state: 2

WNT 2.0 / 3.0

Handling gateway status event message
Gateway offline: <gateway_id> 

Application configuration

Getting and setting

The test verifies that application configuration and diagnostics interval are set and get correctly.

  • Shut down the gateway
  • Stop the WNT services
docker-compose down
  • Delete MQTT broker's storage

WNT 1.7 / 2.0

docker volume rm wnt_mosquittodb

WNT 3.0

docker volume rm wnt_vernemq_data
  • Start the WNT services and print the log
docker-compose up -d; docker-compose logs -ft
  • Start the gateway
  • Verify that sink can be seen from gateway_communicator's prints
Checking for removed pseudo ids
========== PSEUDO ID TO SINK START ==========
Sink: <gateway_id>/sink<sink_id> (<network_id>:<node_id>) -
=========== PSEUDO ID TO SINK END ===========
========== NETWORK ID TO SINK LIST START ==========
Network id: <network_id>
Sink: <gateway_id>/sink<sink_id> (<network_id>:<node_id>) -
=========== NETWORK ID TO SINK LIST END ===========
  • Set the application data and diagnostics interval with the WNT client

WNT 1.7 / 2.0

WNT 3.0

  • Verify from the WNT client that the sink shows the same application data and diagnostics interval in the sinks list that what was set earlier.
  • Verify the successful setting also from the gateway_communicator's prints
Handle set config response message
Set config succeeded
  • Close the WNT client (*** rerun from here ***)
  • Stop the WNT services
docker-compose down
  • Delete MQTT broker's storage

WNT 1.7 / 2.0

docker volume rm wnt_mosquittodb

WNT 3.0

docker volume rm wnt_vernemq_data
  • Start the WNT services and print the log
docker-compose up -d; docker-compose logs -ft
  • Start the WNT client
  • Verify from the Networks page under Settings that the sink shows the same data that was previously set. Also see that application data in the sink's line shows all the 80 bytes with the leading and/or following zeros.
  • Rerun steps from the (*** rerun from here ***) mark but also restart the gateway during the time that WNT services are down
  • From the Nodes page double click sink line
  • Verify from the Boots tab that the sink did not reboot during the time when the application configuration was changed

Remote API

Changing sink's node id

Test that sink's node id can be changed.

  • See that WNT services are running, printing logs and the gateway is on
  • Start the WNT client
  • Select the sink's network from the left top network selection control

  • Go to node configuration under settings and select the sink in the Unicast tab

  • Add Node address to the Selected attributes and change it to be distinct in the network

  • Press Continue button so process page is opened
  • See that values are correct and press Start configuration button
  • Wait that Configuration step is ready and Responses show 1 / 1

  • Change activation delay to four minutes and press Start activation
  • Wait for four minutes so the node configuration is activated
  • See that Activation step's Responses show 1 / 1 and after few minutes, Reboot step show also 1 / 1 in the Sinks rebooted field.

  • Press Finish
  • Verify from gateway communicator's logs that only new sink node id is reported
Checking for removed pseudo ids
========== PSEUDO ID TO SINK START ==========
Sink: <gateway_id>/sink<sink_id> (<network_id>:<new_node_id>) -
=========== PSEUDO ID TO SINK END ===========
========== NETWORK ID TO SINK LIST START ==========
Network id: <network_id>
Sink: <gateway_id>/sink<sink_id> (<network_id>:<new_node_id>) -
=========== NETWORK ID TO SINK LIST END ===========
  • Restart the gateway and verify that gateway communicator still prints only the new node id

Setting keys

Verify encryption keys setting.

  • See that WNT services are running, printing logs and the gateway is on
  • Start the WNT client
  • Select the sink's network from the left top network selection control

  • Go to Node configuration under Settings and select the Broadcast tab

  • Add Cipher key and Authentication key to the Selected attributes and set both values to 112233AABBCC

  • Press Continue button so process page is opened
  • See that values are correct and press Start configuration button
  • Wait that Configuration step is ready and Responses show 1 / 1

  • Change Activation delay to four minutes and press Start activation
  • Wait for four minutes that the node configuration is activated
  • See that Activation step's Responses shows 1 / 1 and after minute or two, Reboot step shows also 1 / 1 in the Sinks rebooted field.

  • Press Finish
  • From the Nodes page double click the sink line
  • Verify from the Information tab that sink shows that security is on

  • Rerun all the steps, but set the keys as the default values in the WNT client FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF (keys inactive) and verify that the Security enabled value is set to False.

OTAP

Firmware update

Please note that for OTAP testing WNT 2.0 or newer is required.

  • See that WNT services are running, printing logs and the gateway is on
  • Start the WNT client
  • Select the sink's network from the left top network selection control

  • Go to Node update under Settings and press Run once to query scratchpad information

  • Browse for scratchpad file and see that Processed FW scratchpad area id and Processed application scratchpad area id match to the Area ids in the image

  • Press Continue button so process page is opened
  • See that values are correct and press Start scratchpad loading button
  • Wait that Loading step is ready and Loaded show 1 / 1

  • Change Activation delay to four minutes and press Start activation
  • Wait for four minutes that the node update is activated
  • See that Activation step's Responses shows 0 / 0 and after few minutes, Status step shows 1 / 1 in the FW and Application fields.

  • Press Finish

Performance and stability

For these tests run the backend and gateway with the sink and nodes at least for 24 hours. Diagnostics interval should be as short as possible. 

No extra sink boots

  • From the Nodes page double click the sink line
  • Verify from the Boots tab that sink did not reboot during the test time

Sink online

  • From the Nodes page double click the sink line
  • Click Online status line
  • Verify from the chart that sink was online for the duration of the test

Sink's packet travel times

  • From the Nodes page double click the sink line
  • Click Uplink delay for normal priority (min/avg/max) line
  • Verify from the chart that maximum travel time is under 100ms

Single gateway multiple sinks

If the gateway supports multiple sinks, create a configuration where there are two sinks in network A and one or more sinks in network B. Rerun all the tests with this configuration.
 Notes:

  • Remote API
    • Broadcast
      • Run the process for both networks concurrently
    • Unicast
      • Run the process for all the sinks concurrently
  • OTAP
    • Update both networks concurrently

References

[1] Gateway to Backend API https://github.com/wirepas/backend-apis/tree/master/gateway_to_backend

Revision History

Date

Version

Notes

v1.1A


Legal Notice

Use of this document is strictly subject to Wirepas’ Terms of Use and Legal Notice.

Copyright © 2021 Wirepas Oy