Troubleshooting Guide – Network Communication
All of Growlink’s controllers communicate with a device cloud, which allows one to remotely view sensor data from the controller, as well as make configuration changes to the controller. If one of our controllers lose their network connection, they will be unable to post their data to our device cloud and one will not be able to make changes to the controller’s configuration without this network connection being restored.
However, as long as the controller has only lost its network connection and has not lost power, the controller will still be able to operate its last known-good rule configuration since Growlink controllers download their rulesets to local memory.
This troubleshooting guide is broken up into three sections, one for legacy hardware using Particle Cloud (EC-1/3/6, SW-1/2, SS-1’s, and Photon PIC’s), current hardware utilizing Azure IoT (Growlink Cores, RevPi’s, Connect Controllers, and ESP PIC’s), and common troubleshooting steps one can take to resolve issues with wireless controller’s connectivity.
Legacy Hardware (Photon)
Network Configuration Troubleshooting
Generally speaking, photon controllers communicating via Particle Cloud do not require any special firewall access or network configuration. In some cases though, some outbound communication may be restricted. Here are the two types of outbound requests our controllers will make to Particle Cloud.
device.spark.io
TCP, port 5683
glprod-deviceapi.azurewebsites.net
glprod-iotapi.azurewebsites.net
52.173.245.249
52.165.156.191
52.176.52.126
52.165.163.22
13.89.235.9
HTTP, port 80/443
ESP Devices and Cores (Azure)
Network Configuration Troubleshooting
Most current hardware (Cores, RevPi’s Connect Controllers, V11 ESP PIC’s) have an Ethernet port and are able to be hard-wired to the network. Provided that the network the controller is connected to is not having ports blocked, the controllers should be able to communicate with Azure IoT with no issue. If one is having difficulty getting your hard-wired controllers connected to the network, one may need to ensure that the following ports are not being blocked:
Ports 5671, 443, and 8883
These are the ports that our controllers utilize to make outbound requests towards our device cloud, and blocking these ports can result in the controller not providing any data using the Growlink Mobile App or Web Portal.
Wireless Controller will not Connect to Network
Certain Photon devices such as irrigation controllers are known to reconnect to the network often and potentially lock up during the reconnection process if the network has certain settings enabled. This will cause them to be unreachable and not transmit data. The following items are potential problem areas to look at with the customer's IT contacts:
2.4GHz band should only be used. Disable 5GHz band if it's enabled. The Photon can only utilize 2.4GHz.
ARP Broadcast Filtering. If there is a lot of 2.4GHz network traffic occurring on the network this filtering being enabled will clean up the network, allowing for a more stable connection.
Wireless Controller Not Staying Connected to Network
In most cases where a controller has network credentials but is routinely losing its network connection, the primary two factors resulting in this behavior is a poor signal strength being received by the nearest Access Point, or the site utilizing a Mesh Network and the controller being bounced between Access Points on the network as a result.
For the former case, moving the controller closer to the nearest Access Point to bolster the signal strength received will ensure that the controller receives a stronger signal strength. If a controller receives a signal strength weaker than -55 RSSI, the controller is likely to lose its network connection to our device cloud over time.
For the latter case, one can configure the Access Points within your Mesh Network to primarily force the controller to connect to the nearest Access Point in the Mesh Network, which will prevent the controller from being bounced between two different Access Points within the Mesh Network setup.
Shared Device Will not Open When Called From a Different Controller
When an output on one controller is shared to another and is called to activate by a rule held on a separate controller (like Master Valves on a Central Feed System and a Zone valve in a Flower Room), our controllers emit a UDP broadcast on the local network in order to command the controller who is wired to the valve to activate that output. If that UDP broadcast is being blocked, rerouted, or the two controllers are on separate networks, the UDP broadcast will not reach the designated controller and the output will remain in Auto-Off instead of Auto-On.
The most common cause of this behavior is the two controllers being on different subnets within the same network, or firewall rules blocking UDP traffic between controllers. Ensuring that the two controllers are on the same subnet and reaching out to your IT team to ensure that UDP traffic isn't being rerouted or blocked across the network can help restore that lost functionality.