Bakery — Proofing chamber over VPN

Complete use case for an artisan bakery that wants to monitor its proofing chamber (temperature 24–30°C, humidity 70–85%) and receive WhatsApp alerts when something goes out of range. The customer doesn't know the PLC brand, doesn't have enterprise networking gear, and starts from zero.

Scenario

El Sol Bakery. A proofing chamber with an industrial PLC in the control cabinet. No manual, no in-house automation technician. The bakery already lost a batch of sourdough (~$300 in product) because nobody noticed the chamber dropped to 18°C for 3 hours overnight.

Goal: WhatsApp alert within 5 minutes when temperature drifts out of range.

Architecture choice: VPN + cloud_direct instead of edge gateway, because the owner already plans to add the rotary oven and mixers next quarter — VPN scales better for multiple machines on the same plant.

What this case is for

It fits if you are:

• Connecting your first industrial equipment to a monitoring system.
• Without access to the PLC manual (legacy install, vendor gone, manual lost).
• With a home-ISP router and no corporate VPN or dedicated IT infrastructure.
• Planning to add more machines to the same plant.

How it works

End-to-end flow:

Proofing chamber (PLC 192.168.1.50)
        │ Modbus TCP :502
        ▼
Mikrotik hAP ac3 router (bakery LAN)
        │ WireGuard UDP 51820 outbound
        ▼
Rela AI Concentrator (europe-west1)
        │ Direct VPC Egress
        ▼
Cloud Run Worker
        │ poll every 5s
        ▼
Pipeline: normalization → rules → notification
        │ WhatsApp via Evolution API
        ▼
Bakery owner's phone

Benefits

Step by step

Step 0 — Identify the PLC (30 min)

Power off the chamber. Open the control cabinet. Look for a rectangular black/gray block on a DIN rail with a label. The 4 common suspects in a bakery:

Take a phone photo of the full label (model + serial).

If you can't or don't want to open the cabinet:

• Search the chamber model (e.g. "MIWE GVA 8") on Google. The datasheet usually mentions the PLC.
• Call the technician who sold/installed it.

Step 1 — Confirm Modbus TCP (15 min)

Google <brand> <model> Modbus TCP. You'll find:

• 99% of PLCs post-2015 with an Ethernet port: Modbus TCP built-in. Done.
• PLCs with only serial RS-485 (A/B/GND terminal): you need a Moxa MGate MB3170 adapter (~$200 USD).
• Siemens LOGO! versions before 8.3: no native Modbus TCP — check upgrade path or consider replacement.

Step 2 — Connect the PLC to the network (1 hour + cabling)

If the PLC isn't already on the network:

1. Run Ethernet cable (Cat5e or Cat6) from the bakery's ISP router to the electrical cabinet. Max 80m.
2. Plug the cable into the PLC's Ethernet port.
3. Assign a static IP (NOT DHCP) to the PLC — typically via the manufacturer's software or the HMI touchscreen:
   • IP: 192.168.1.50
   • Mask: 255.255.255.0
   • Gateway: ISP router's IP

If you haven't worked with PLCs before, this step is done by the chamber vendor's tech in 15 minutes.

Step 3 — Buy the VPN router

Mikrotik hAP ac3 (~$80 USD). Native WireGuard support, palm-sized, 5W power draw.

Acceptable alternatives: any Mikrotik with RouterOS 7+, pfSense, OPNsense, Ubiquiti EdgeRouter. What doesn't work: regular ISP routers (TP-Link / Mercusys / cable-modem), no WireGuard support.

Step 4 — Install the Mikrotik alongside the ISP router

Simplest layout:

[ISP Modem/Router] ─── [Bakery switch/cabling] ─── [Mikrotik hAP ac3]
                                │                           │
                                ▼                           ▼
                        [Office equipment]          [Chamber PLC]

The Mikrotik shares the same network but terminates the tunnel. Its only job: receive packets from the VPN and forward them to the PLC.

Step 5 — Create your account + VPN peer in Rela AI

1. Sign up at rela-ai.io.
2. Dashboard → Settings → VPN Connectivity → Create tunnel.
3. Name: El Sol Bakery - Main Site. Save.
4. The system shows:
   • Assigned subnet: 10.200.7.0/24 (yours will differ).
   • "Waiting for first handshake…" widget.
   • Equipment selector with 7 options.

Step 6 — Download the Mikrotik config

In the equipment selector, pick Mikrotik RouterOS. Click Download config. You get rela-vpn-mikrotik.rsc.

Step 7 — Paste the config on the Mikrotik

Log into the Mikrotik web console (http://192.168.88.1) → New Terminal → paste the entire .rsc content with Ctrl+V.

Verify the interface was created:

/interface wireguard print

Step 8 — Add 1:1 DNAT (the critical step)

The step that's easy to forget and breaks everything. Your PLC is at 192.168.1.50 (internal IP), but Rela AI sends packets to an IP inside your assigned VPN subnet, e.g. 10.200.7.50. The Mikrotik must translate those IPs 1:1 to the real PLC.

Technical reason: each site gets a unique VPN subnet (10.200.X.0/24). The tunnel only carries traffic for that subnet. Internal IPs like 192.168.1.50 collide across customers (everyone uses them), so they can't go directly through the tunnel — they must be mapped.

1:1 DNAT rule on your Mikrotik (one line per PLC):

/ip firewall nat
add chain=dstnat dst-address=10.200.7.50 dst-port=502 protocol=tcp \
    action=dst-nat to-addresses=192.168.1.50 to-ports=502

/ip firewall filter
add action=accept chain=forward in-interface=rela-vpn src-address=10.200.0.0/16

If you have multiple PLCs (oven, mixer…), one DNAT rule per PLC with distinct addresses inside your VPN subnet (e.g. 10.200.7.50 → chamber, 10.200.7.51 → oven).

Step 9 — Verify handshake

Back in the dashboard → /settings/connectivity. Within 10-30 seconds, the widget should flip to Connected with:

• Latest handshake: under 30 seconds.
• RX and TX: positive values rising.

If it's still waiting:

• Your ISP firewall blocks outbound UDP 51820. Ask your ISP to open it (rare but happens).
• The public key was truncated on copy. Re-download the config.

Step 10 — Create the Modbus source

Dashboard → Alarms → Sources → New source:

Important: the host is 10.200.7.50 (the DNAT IP from step 8), not 192.168.1.50. The Mikrotik handles the translation to the real PLC.

Add an exploratory register:

Save → Test connection → rtt_ms: ~120, value around 245 if the chamber is at 24.5°C.

Step 11 — Discover the register map without a manual

If the test works but you don't know which address maps to what variable, use blind scanning:

1. Install Modbus Poll (Windows, free trial) on a laptop inside the LAN.
2. Connect to the PLC: 192.168.1.50:502, slave 1.
3. Read holding from address 0 to 100 — a table of 100 values appears.
4. In the chamber, change the temperature setpoint from 24 to 28°C.
5. Watch which cell changed (from ~240 to ~280). That's your temperature register.
6. Repeat for humidity: change the humidity setpoint and find the cell that moved.

Write down:

• holding[0] → temperature × 10 (uint16)
• holding[1] → humidity × 10 (uint16)
• holding[2] → temperature setpoint
• coil[0] → fan motor (bool)

Step 12 — Create agent and alarm rule

Dashboard → Agents → New:

• Name: Proofing Chamber Agent.
• Assign source: Proofing chamber.

Rules → New:

Step 13 — End-to-end validation

1. Open the chamber door and leave it open for 10 minutes. Temperature drops.
2. At the 5-minute mark, your phone buzzes: "Temperature proofing chamber: 18°C — out of lower range (22°C)".
3. Dashboard → Inbox shows the high-severity alert.
4. Close the door. In ~10 minutes temperature is back in range and the alert auto-closes.

If all 4 checks pass, the system is operational.

Scaling to more machines in the same bakery

A single VPN tunnel serves every machine in the bakery. When you add the rotary oven:

1. Give it a fixed IP (e.g. 192.168.1.51) on the same network.
2. Dashboard → Sources → New → protocol the oven speaks (Modbus TCP / OPC UA / S7).
3. Same deployment_mode=cloud_direct, host 192.168.1.51.
4. Don't touch the Mikrotik or the VPN.

The general rule: 1 tunnel per physical site. The bakery has 1 site, so 1 tunnel. Individual machines are sources within the same tunnel.

Real costs

Estimated ROI: one $300 sourdough batch saved by early alert covers the first 4 months of subscription. Most industrial bakeries recover the investment on the first prevented incident.

Limitations and assumptions

• Not for control loops: polling every 5s doesn't replace the PLC's PID control. Rela AI monitors, doesn't control.
• Requires internet at the bakery: if the connection drops, no local buffering (that's what the edge path is for). A 30-minute outage means 30 minutes without monitoring.
• One VPN router per site: if the bakery has a second location in another city, that location needs its own VPN peer (Enterprise plan allows up to 5 sites).

Next steps after this case

Once the chamber is monitored, the usual path is:

1. Add the rotary oven and mixers under the same VPN.
2. Configure a differentiated agent per machine type.
3. Add an operational KPI dashboard.
4. Configure weekly email reports.
5. If you scale to multiple locations, upgrade to Enterprise plan.

See also: VPN Connectivity — technical guide, How to test the VPN works, Modbus TCP connection.