Rolling out Open Kitchen across your locations raises important IT questions — from network requirements and bandwidth to security and failover planning. The FAQs below cover what your team needs to know before, during, and after deployment.
Kitchen equipment (ovens, grills, fryers) connects via Wi-Fi on your existing network. Refrigeration and temperature sensors use a 915 MHz radio protocol to communicate locally to the Open Kitchen Gateway — they do not touch your Wi-Fi network at all. The Gateway itself connects to your network via a hardwired Ethernet port.
All equipment connectivity modules support WiFi or Ethernet. WiFi is recommended for movable equipment; Ethernet for fixed equipment as it is more reliable but requires cabling. The gateway/hub is the single device that connects to your customer network.
Data usage is extremely low. Devices send small telemetry packets roughly once per minute under normal conditions, more frequently if an alert event occurs. The protocol is optimized for low-power, low-bandwidth operation. No video, audio, or large file transfers are involved.
Temperature and energy sensors use a proprietary radio protocol and do not have IP addresses — they communicate locally to the Gateway, not through your IP network. Only the Gateway itself requires an IP address and network access. Kitchen equipment (ovens, etc.) can be placed on a dedicated VLAN with no requirement to share a subnet with the Gateway.
No — energy and temperature sensors communicate directly to the gateway via proprietary radio (not WiFi). Only kitchen equipment (ovens, grills, etc.) uses the customer WiFi network.
Yes. A gateway (hub) is required for energy management and temperature sensors. The gateway is the only device on the customer network — sensors communicate directly to it, and it sends data to the cloud.
Typically near or in the network rack. Avoid harsh kitchen environments with grease or heavy cleaning exposure.
Yes. Multiple gateways are recommended for large sites or deployments with many sensors (approximately 30+).
The radio for battery-powered wireless temperature sensors operates at 915 MHz in North America and 868 MHz in Europe. Sensors communicate directly to the gateway, not over WiFi. The radio for thermostats and energy monitors uses the MiWi protocol (802.15.4) and operates at 2.4 GHz.
Hardwired sensors are preferred for reliability and can typically run hundreds of feet. An alternative is an external wireless sensor with a probe into the cooler, though wireless performance inside metal coolers can be limited.
No. The system is wholly outbound — no open inbound ports and no listening services. All data flows out via HTTPS (port 443). Any commands from the cloud are sent only in response to an outbound message from the device. No VPN tunnels or special firewall rule changes are required beyond allowing standard HTTPS egress.
No. Devices use store-and-forward — data is buffered locally and sent once connectivity returns. See the Power Outage section for specifics on data retention.
Kitchen equipment connector modules store data locally on the device and forward it when connectivity resumes (approximately two weeks of capacity for a single oven). Battery-powered wireless temperature sensors send their data to the Gateway, where the data buffers until connectivity is restored.
To mitigate the impact of a power outage, the Gateway can be placed on a UPS or a PoE switch backed by UPS so the gateway will continue to cache data from the temperature sensors until power is restored. The food-safety target is 4–6 hours of coverage to validate temperature safety decisions.
Yes, if the gateway remained powered throughout the outage. No, if the gateway lost power — unless it was backed by a UPS. Kitchen equipment modules store data locally and will forward it once connectivity resumes.
Yes. The platform supports SAML-based SSO. There is no native identity and access management (IAM) integration built in, but it can be configured as a SAML 2.0 identity provider. Confirm with your identity team whether your tenant can issue a SAML 2.0 assertion to a third-party service provider.
Alerts can be delivered via email, SMS, mobile push notification, and syslog. Webhooks are supported for pushing events to external systems. A REST API is available to pull data from the cloud. SNMP is not supported. Alert thresholds, duration windows, operating-hours schedules, and per-user notification preferences are all configurable in the dashboard.
Walk-in cooler wiring: install conduit early to make hardwiring sensors easier. Gateway placement should be consistent and away from kitchen grease/cleaning areas. Wireless limitations exist inside metal coolers. Large sites with 30+ sensors may require multiple gateways.
Possibly, but commissaries often use more advanced industrial systems (e.g., BMS). Integration approach may differ — confirm scope with your implementation team.
BOOK A DEMO
