Overview #

DicksonOne is a system that combines network-connected data loggers and cloud-based software (i.e. an internet of Things or IoT platform). Depending on your organization’s IT requirements/controls, you may need to collaborate with your IT team to get approval to use the system on your company’s network and ensure the system will work once installed.

DicksonOne features two different regional servers: NA and EMEA/APAC.   When configuring your loggers (DWE2/TWP) or gateways, double check to confirm if your account is registered on the NA server (dicksonone.com) or the EMEA/APAC server (eu.dicksonone.com).   The server endpoint will be different for each server.  DWE2/TWP loggers and Gateways are configured, during installation.   RFL / RF868 loggers are provisioned at Dickson.   Sales will confirm the host server for your account to ensure RFL / RFL868 loggers are provisioned correctly.

The IT infrastructure and environment varies drastically from one organization to the next. As such, if you have any additional questions please feel free to reach out to us for more information. Below are some answers to the most common questions and concerns from an IT perspective.

Data Loggers (DWE/DWE2/TWE/TWP) #

• As of Q4 2023, loggers only communicate via Port 443 (HTTPS); older versions of firmware were configurable for either Port 80 (HTTP) or Port 443
• As a best practice, all communication is generated by the data loggers
  • For these devices, there’s no opening of ports is necessary 
  • There are no incoming commands/control/access for these devices
• The devices have a proprietary OS/firmware (i.e. NOT Windows CE, Linux, Android, etc)
• Devices support both WiFi and ethernet, but only one at a time
• Supported network types include 2.4Ghz B/G/N 
• Supported encryption protocols:
  • WEP
  • WPA Personal
  • WPA Enterprise
  • WPA2 Personal
  • WPA2 Enterprise (with some certificates; excludes the DWE2)
• Organizations who use WPA/2 Enterprise protocols may want to consider a dedicated user for authentication which does not require password changes on a regular basis as the need to update the password regularly across many devices might be burdensome for some organizations; consider a VLAN to reduce any associated risks. 
• TWE/TWPs are proxy aware while DWEs are not 
• Devices are not compatible with a captive portal without additional network configuration (e.g. safe-listing MAC addresses, see below)

First generation DicksonOne loggers (black plastic cases) are compatible with wireless B networks. Your access points must be configured to Wireless B or utilize a compatibility mode.

DWE2 and MDIX  #

The DWE2 does not support auto MDIX at this time and may result in your loggers not being able to connect to a network if switches aren’t configured correctly and/or the correct ethernet cables are in use. 

To avoid MDIX related issues, you can either:

1. Enable Auto MDIX on the network switch 
2. Use a crossover ethernet cable between the logger and a switch which does not have Auto MDIX enabled

RF LoRa Logging System #

LoRa System Components

A LoRa network consists of several pieces of hardware:

• End points (e.g. RFL or RF868 Logger):   The endpoints are the loggers on the LoRa network where the readings and data are taken. 
• LoRa gateway (e.g. RFG Gateway) :   The gateway receives the communications from the LoRa endpoints and then transfers them to a network server. The gateway is the only device treated as a client on a physical network.  Gateways are connected to the network via WiFi, Ethernet, or Cellular.
• LoRa Network Server (e.g. The Things Network):   The LoRa network server enables connectivity, management, and monitoring of devices, gateways, and end-user applications. Its main objectives are to ensure the security, scalability, and reliability of data routing throughout the network.
• Remote computer (The user):   a remote computer can then control the actions of the endpoints or collect data from them 

LoRa System requirements 

Dickson has two main LoRa data loggers: the RFL and the Cobalt.

For the RFL data logger:

• The device is compatible with the RFG and RFG-LTE gateways:
• RFLs utilize the LoRa protocol to communicate information back to a gateway which uses WiFi, Ethernet, or Cellular for a backhaul
• The LoRa Gateways must be able to make an outgoing connection using UDP port 1700 and receive all replies
• The RFL has proprietary  OS/firmware (i.e. NOT Windows CE, Linux, Android, etc) while the RFG and RFG-LTE run Linux
• IMPORTANT: The account host server location determines which LoRa server the RFL / RF868 loggers must be provisioned to.

For the Cobalt X data logger:

• The device is compatible with the Pro and Advanced gateways
• Cobalt X’s utilize the LoRa protocol to communicate information back to a gateway which uses WiFi, Ethernet, or Cellular for a backhaul
• The LoRa Gateways must be able to make an outgoing connection using UDP port 1700 and receive all replies
• The Cobalt X has a proprietary OS/firmware (i.e. NOT Windows CE, Linux, Android, etc) while the compatible gateways run Linux

For the RFG gateways: #

Note on Tracking IPs and Network Interface Failover:

The RFG Gateway uses tracking IPs to determine whether failover between network interfaces (Ethernet, WiFi, Cellular) is necessary. These tracking IPs are reached using outbound ICMP (ping) requests.

Important:
If the tracking IPs are blocked by the customer firewall, the gateway may incorrectly assume that its active interface is down and attempt to fail over. This can result in unstable connectivity, loggers falling behind, or gateways flashing red appearing offline in DicksonOne.

Best Practice:
If outbound ICMP is blocked on the customer’s network, consider updating the tracking IPs to a reachable and stable internal resource, such as a local DNS server or gateway. This has proven effective at resolving connectivity issues in environments with strict outbound filtering.

VLANs #

It is common for users of the DicksonOne monitoring system to utilize VLANs as part of their deployments. Many organizations have an “IoT” network dedicated to products and services like DicksonOne. 

Local IP Addresses #

Devices can be configured in either DHCP or via a static IP address. If using DHCP, ensure the devices are allowed to receive their own IP addresses via your DHCP server.

We recommend DHCP reservations via MAC address instead of static IP addresses but devices can be configured according to your company’s policies.

Safe-listing Application IP Addresses/FQDNs for Firewalls #

DicksonOne utilizes application load balancers as part of its high availability design and cannot currently offer a static IP address for the purpose of safe-listing at this time. As an alternative, we recommend safe-listing the FQDNs which are commonly supported by most firewall/networking equipment these days.

If your organization requires safe-listing applications via IP addresses or FQDNs, please ensure the table below to ensure the domains are on your safe-lists:

FQDN	Port	Protocol	Rel. Product	Description
dicksonone.com (NA Server) eu.dicksonone.com (EMEA/APAC Server)	443	TCP	DWE TWE TWP	Device communication to/from the cloud software and user interface
api.dicksonone.com (NA Server) api.eu.dicksonone.com (EMEA/APAC Server)	443	TCP	DWE/2 TWE TWP RFG	Device communication to/from the cloud software
dicksonone.nam1.cloud.thethings.industries (NA Server) dicksonone.eu1.cloud.thethings.industries (EMEA/APAC Server)	1700	UDP	RFG	Communication between LoRa devices/gateways and the application
s3.amazonaws.com	443	TCP	DWE/2 TWE TWP RFG	Over the air (OTA) firmware updates for supported devices
time.nist.gov		NTP	DWE/2 TWE TWP	External time server to ensure accurate time tracking on data loggers
Note: If your company utilizes firewalls, web filtering, or proxies ensure they are not blocking packets TO or FROM DicksonOne.

MAC address filtering #

If your organization utilizes MAC address filtering, the MAC address can be found for each device according to the table below.

Device	MAC Address Available	Location
DWE/2	Yes	Network Connection Widget
TWE & TWP	Yes	Information Screen on device
RFL	Not Applicable	Not Applicable
RFG RFG-LTE	Yes	Label on the Device Administrative screen
Cobalt X	Not Applicable	Not Applicable
Pro Gateway / Advanced Gateway	Yes	Label on the Device Administrative screen

Backup Data Independently from DicksonOne #

While DicksonOne has adequate redundancy built into the system, customers often ask how they can back up their data on their own servers. 

This can be accomplished in multiple ways:

• Manually exporting CSV files from the devices on a regular basis that can be stored on an organization’s servers
• Automatically configuring PDF reports that can be stored on an organization’s servers
• Leverage the available REST API to integrate a backup of your data onto your own servers or with a third-party system such as a Building Management System. More information on the REST API can be found below.

Integrations & REST APIs #

DicksonOne offers a robust REST API for custom integrations. If your organization has access to developers and/or other IT staff who are familiar with and capable of working with REST APIs, you can utilize the APIs to integrate with a variety of systems or use cases including:

• ERP/MRP
• QMS
• Business Intelligence (Tableau, Power BI, etc)
• Custom dashboarding
• Custom backup solutions

Documentation for the DicksonOne REST APIs can be found here: https://www.dicksonone.com/developers.

WiFi Access Points #

If your facility uses multiple access points with the same SSID and security key to cover a large area, ensure the following: the device’s encryption type set to Auto Select and the security keys are identical. We highly recommend that any two access points within range of one another are configured to use channels that do not overlap one another.

Most access points have a limit to how many devices can concurrently be connected. This varies, but is often as few as 25. Consider laptops, cell phones, equipment, loggers, and any other devices that may be connected to an access point.

---