Overview
The lists below show the technical requirements before connecting an SLP to a network.
Wi-Fi Requirements
SLP can only connect to Wi-Fi channels 1 to 11.
SLP can only connect to a 2.4Ghz Network. To extend the SLP's battery endurance, 5Ghz is unsupported as it consumes much more power.
SLP supports WPA and WPA2 but doesn't support WPA3.
Wi-Fi MAC filter or any other kind of filtering should be disabled.
The signal strength should be above -70dBm for smooth communication. The locks use ultra-low-power Wi-Fi chips, which require strong signals to operate properly.
Note
You can find the MAC Address under the Wi-Fi section from the Portal Staff App > Lock Details > Wi-Fi.
For the network to not switch between 2.4 GHz and 5 GHz, the band shifting setting needs to be turned off.
Other Network Requirements
To let the SLP communicate with Portal's servers, please ensure the network configuration meets the following requirements:
Allow server access: the smart locks communicate on TCP port 4999. Make sure the port is open on the firewall.
⚠️ Flagged for review: this port requirement is confirmed for the Goki implementation of this same hardware. The exact hostname/port for Portal-connected SLPs has not yet been separately confirmed with engineering — please verify before treating this as final for Portal.
Access to the Internet: the smart locks should be able to access the Internet without authenticating on any authentication server.
Public and Private IP Addressing: as smart locks use private IP addresses within the local network, configure NAT to map these private addresses to a single public IP address when communicating with external servers or cloud services. The "IP Load Balancing" feature and "Asymmetric Routing" problem on firewalls are relevant to this requirement.
Address Reservation: reserve IP addresses for smart locks in the DHCP server configuration. This ensures that each smart lock receives the same IP address upon renewal.
Lease Duration: adjust DHCP lease durations to match the expected connectivity patterns of smart locks. Longer lease durations can reduce network traffic associated with frequent address renewals.
Separate Subnets: consider placing smart locks on a separate subnet using VLANs. This can help logically isolate smart lock traffic and simplify DHCP management for that specific subnet.
QoS Policies: QoS policy configuration may prevent smart lock traffic from passing through the network effectively. We advise implementing QoS policies to prioritize smart lock traffic, ensuring it receives sufficient bandwidth and low latency to operate effectively.
DoS Protection Policies: DoS protection policies could mark lock server traffic as a threat. Ensure there are no such policies interfering with lock communication.
5G is not supported — only 2.4G is supported. When the band shifts, the locks will go offline; make sure to untick that setting and review network best practices with a network engineer.