An olive grove and a block of greenhouses in the Cretan interior: soil probes scattered over thirty hectares, climate and irrigation controllers that have to keep running, a packing shed with the only mains power for a kilometre, and no fibre and no town within reach. We build it on MikroTik, LoRaWAN and Starlink in 8 tested steps — and put a camera where the grid doesn't reach.
Full network · all steps built
highlighted = lines added in the selected step · earlier steps shown plain · later steps hidden
This is part of the Build series, and the one that leaves the building. A farm network is not one site — it's a shed with power, a block of greenhouses a few hundred metres away, and sensors scattered across a grove where there is no power, no cable and no Wi-Fi that would ever reach. Three different radio problems, one router, and a link to the outside world that is a dish on a pole.
The design leans on three ideas that none of the earlier builds needed: use the right radio for the distance — LoRa for the grove, long-range Wi-Fi for the greenhouses, Starlink for the world; treat power as a budget, not a given; and keep the things that act — pumps, vents, valves — locked to exactly what they need, because an irrigation controller on the internet is a pump someone else can turn on.
01
A fictional but very typical Cretan operation: 30 ha of olives, a block of six greenhouses, a packing shed, and an agronomist who visits once a week.
The packing shed has the only mains power for a kilometre (grid plus a generator), a small office with two PCs, a scale and label printer for crates, and an NVR for the yard cameras. A block of six greenhouses sits about 600 m away: each has a climate controller (vents, heating, humidity), a fertigation/irrigation controller, and a tablet the grower uses. Across the olive grove, dozens of battery soil-moisture and weather probes report every fifteen minutes. One far corner of the grove needs a camera on a track gate where no cable and no power reach. Internet is Starlink on the shed roof. The agronomist and the operator both work remotely.
| Requirement | Where it comes from, and what it forces |
|---|---|
| R1 Sensors across a grove | Dozens of probes over 30 ha, each running years on a battery. Wi-Fi can't do range or battery life; this is what LoRaWAN exists for. |
| R2 Greenhouses 600 m away | Too far for a cable, too much to trench. A long-range 5 GHz bridge carries the control VLAN across the gap. |
| R3 Controllers that act | Pumps, vents and valves can cause real damage. The controllers must reach their own vendor cloud and nothing else, and nothing may reach them except the office dashboards. |
| R4 A camera off the grid | The gate has no power and no cable. A solar node with its own LTE and battery, sized to ride through cloudy days. |
| R5 One link to the world | Starlink is the only real option out here. A 4G backup covers obstruction and storms; sensor and camera traffic is tiny, so the link is mostly for the office and updates. |
| R6 Remote everything | Starlink and LTE are both behind carrier NAT, and nobody is on site. Management and monitoring dial out over a tunnel. |
| R7 Power is not a given | Grid cuts in summer storms, a generator that runs dry, a battery that sees a week of cloud. Every node has to degrade and recover on its own. |
02
Each is a choice about which radio, and about what a device that controls water is allowed to talk to.
There are three wireless problems here and they are not the same problem. The grove needs kilometres of range and years of battery from tiny messages a few times an hour — that is LoRaWAN, not Wi-Fi. The greenhouses need a real VLAN trunk across 600 m of line of sight — that is a 5 GHz point-to-point bridge. The world needs bandwidth — that is Starlink. Using Wi-Fi for the grove, or LoRa for the greenhouses, would fail in opposite directions.
A LoRaWAN sensor never joins the IP network. It transmits an encrypted frame into the air; the gateway hears it and forwards the raw packet to a network server (here, The Things Stack), which decrypts it and hands the reading to the farm's dashboard. So the grove adds one device to the network — the gateway — on its own small VLAN, and the hundreds of possible sensors add nothing to attack on the wire.
An office PC leaking is a bad day. An irrigation controller reachable from the internet is a pump that floods a field or a greenhouse that cooks its crop. The control VLAN may reach only its vendor's cloud (DNS-pinned), and only the office dashboards may reach it. No sensor, no camera, no guest ever touches it.
The shed has mains; everything else has a budget. The solar node's draw (router + camera + LoRa), times the hours of darkness and a margin for cloudy days, sets the battery; the battery and the worst-month sun set the panel. Get it wrong and the gate camera dies every January. We size it explicitly in step 7, the way you'd size a queue.
03
Seven VLANs. The one that matters most is the smallest: the controllers that move water.
| VLAN · subnet | Who lives here · notes |
|---|---|
| 10 OPS · 10.60.10.0/24 | Office and packing PCs, the scale and label printer. The only VLAN that may reach the controllers and cameras. |
| 20 STAFF · 10.60.20.0/24 | Staff phones and the greenhouse tablets, on Wi-Fi. Internet only. |
| 30 CONTROL · 10.60.30.0/24 | Climate controllers, fertigation/irrigation controllers, greenhouse PLCs. Reach their vendor cloud only; reachable only from OPS. |
| 35 LNS · 10.60.35.0/24 | The LoRaWAN gateway's uplink. One host: the gateway, forwarding to The Things Stack. |
| 40 CCTV · 10.60.40.0/24 | Yard cameras and the NVR, plus the off-grid camera over its tunnel. |
| 50 GUEST · 10.60.50.0/24 | The agronomist and visitors. Internet only, nowhere near the farm's own systems. |
| 99 MGMT · 10.60.99.0/24 | R1 .1, SW-SHED .11, LoRa gw .12, APs and SXT radios. WireGuard to the operator hub: 10.250.0.0/24. |
| WAN | ether1: Starlink bypass (DHCP, CGNAT). ether2: 4G backup (DHCP, CGNAT). The solar node has its own LTE. |
04
Who may start a connection to whom. Everything not listed is dropped by the forward chain in step 5.
| From ↓ / To → | May reach |
|---|---|
| OPS (10) | Control dashboards, cameras/NVR, the internet. |
| STAFF (20) | The internet only. |
| CONTROL (30) | The vendor cloud only (DNS-pinned). Never another VLAN, never another controller it doesn't need. |
| LNS (35) | The Things Stack only. |
| CCTV (40) | The camera vendor cloud only. |
| GUEST (50) | The internet only. |
| MGMT (99) / WireGuard | Everything — this is the operator's and the installer's path, reachable only over the tunnel. |
05
Every requirement from the brief, and the step that satisfies it.
| Req | Satisfied by |
|---|---|
| R1 Sensors across a grove | Step 3 — LoRaWAN gateway + The Things Stack |
| R2 Greenhouses 600 m away | Step 4 — 5 GHz nv2 point-to-point bridge carrying VLAN 30 |
| R3 Controllers that act | Steps 2 + 5 — control VLAN, vendor-only egress, OPS-only ingress |
| R4 A camera off the grid | Step 7 — solar node, LTE backhaul, power budget |
| R5 One link to the world | Step 6 — Starlink bypass + 4G failover |
| R6 Remote everything | Step 8 — dial-out WireGuard, netwatch, remote logs |
| R7 Power is not a given | Steps 7 + 8 — battery sizing, watchdog, auto-recovery |
06 · Step 1 of 8
The packing shed is the only place with power and a rack. Everything wired starts here, VLAN by VLAN.
▲ Show step 1 in the interactive topology · see what this step adds, and click any device for its config
/system identity set name=SW-SHED # enforcement OFF now, ON at the end (lock-out safety) /interface bridge add name=bridge vlan-filtering=no /interface bridge port add bridge=bridge interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged comment="uplink R1 (10G)" # … ether2-3: packing PCs add bridge=bridge interface=ether1 pvid=10 comment="office PC" add bridge=bridge interface=ether4 pvid=10 comment="scale + label printer" add bridge=bridge interface=ether5 pvid=40 comment="NVR" # … ether7-9: yard cams add bridge=bridge interface=ether6 pvid=40 comment="gate camera" add bridge=bridge interface=ether10 pvid=99 comment="LoRa gw (trunk)" add bridge=bridge interface=ether11 pvid=99 comment="shed hAP ax (trunk)" add bridge=bridge interface=ether12 pvid=99 comment="SXT to greenhouses (trunk)" /interface bridge vlan # each VLAN tagged only on ports that must carry it (LoRa trunk never sees the camera VLAN) add bridge=bridge vlan-ids=10,40 tagged=sfp-sfpplus1 add bridge=bridge vlan-ids=20,50,99 tagged=sfp-sfpplus1,ether11 add bridge=bridge vlan-ids=30,99 tagged=sfp-sfpplus1,ether12 add bridge=bridge vlan-ids=35,99 tagged=sfp-sfpplus1,ether10 add bridge=bridge vlan-ids=99 tagged=bridge /interface vlan add name=v99-mgmt interface=bridge vlan-id=99 /ip address add address=10.60.99.11/24 interface=v99-mgmt # just a default gateway (R1) so the switch is reachable /ip route add gateway=10.60.99.1 # disable unused ports — an open jack is an open door /interface ethernet disable ether13,ether14,ether15,ether16,ether17,ether18,ether19,ether20,ether21,ether22,ether23,ether24 /interface bridge set bridge vlan-filtering=yes # now safe to enforce VLANs
The shed switch is where the wired world lands: the office PCs and the crate scale on OPS, the NVR and yard cameras on CCTV, and three trunk ports for the things that carry more than one VLAN — the LoRa gateway, a shed AP, and the SXT radio aimed at the greenhouses. PoE feeds the cameras and the APs; the PCs and the printer don't need it.
/interface bridge vlan print: VLAN 40 is tagged only toward R1, not on the LoRa or SXT trunks.R gone in /interface print.07 · Step 2 of 8
One RB5009 in the shed is the gateway for all seven VLANs and the firewall between them.
▲ Show step 2 in the interactive topology · select R1 for its config
/system identity set name=R1 /interface bridge add name=bridge vlan-filtering=no /interface bridge port add bridge=bridge interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged comment="SW-SHED" /interface bridge vlan add bridge=bridge vlan-ids=10,20,30,35,40,50,99 tagged=bridge,sfp-sfpplus1 /interface vlan # one interface per VLAN = router-on-a-stick; each is that VLAN's gateway add name=v10-ops interface=bridge vlan-id=10 add name=v20-staff interface=bridge vlan-id=20 add name=v30-control interface=bridge vlan-id=30 add name=v35-lns interface=bridge vlan-id=35 add name=v40-cctv interface=bridge vlan-id=40 add name=v50-guest interface=bridge vlan-id=50 add name=v99-mgmt interface=bridge vlan-id=99 /ip address add address=10.60.10.1/24 interface=v10-ops add address=10.60.20.1/24 interface=v20-staff add address=10.60.30.1/24 interface=v30-control add address=10.60.35.1/24 interface=v35-lns add address=10.60.40.1/24 interface=v40-cctv add address=10.60.50.1/24 interface=v50-guest add address=10.60.99.1/24 interface=v99-mgmt # staff/guest get short leases; controllers + gateway get reservations /ip dhcp-server add name=d-staff interface=v20-staff address-pool=p-staff lease-time=4h /ip dhcp-server add name=d-guest interface=v50-guest address-pool=p-guest lease-time=2h # … ops, control (reservations), lns (reservation), cctv networks the same way /ip dns set allow-remote-requests=yes servers=9.9.9.9,149.112.112.112 /system ntp client set enabled=yes servers=time.cloudflare.com /interface bridge set bridge vlan-filtering=yes
A single trunk between R1 and the switch carries all seven VLANs tagged; R1 holds a gateway address on each. The controllers and the LoRa gateway get DHCP reservations rather than dynamic leases — a fertigation controller whose address moves is a dashboard that stops working mid-season. DNS upstream is Quad9; the controllers are pointed at R1 so their vendor lookups can be watched and, if needed, pinned.
/ip dhcp-server lease print shows the reservations as D (dynamic) only where you meant them to be.08 · Step 3 of 8
One box turns a radio full of encrypted sensor frames into rows in a dashboard — and it is the only thing the grove puts on the network.
▲ Show step 3 in the interactive topology · select LoRa GW for its config
# sensors are RF endpoints (OTAA to the LNS); the gateway only relays frames — no IP on the grove/system identity set name=LORA-GW # ether1 is the trunk from SW-SHED /interface vlan add name=v35-lns interface=ether1 vlan-id=35 /interface vlan add name=v99-mgmt interface=ether1 vlan-id=99 /ip address add address=10.60.35.10/24 interface=v35-lns /ip address add address=10.60.99.12/24 interface=v99-mgmt /ip route add gateway=10.60.35.1 /ip dns set servers=10.60.35.1 # Semtech UDP packet-forwarder to The Things Stack (EU868) /iot lora servers add name=tts address=eu1.cloud.thethings.network up-port=1700 down-port=1700 /iot lora set lora0 servers=tts network=public antenna-gain=3
LoRaWAN splits the job in two. The sensor wakes a few times an hour, sends one small encrypted frame, and sleeps — which is how a coin cell lasts years. The gateway is a dumb, powerful ear: it hears every frame in range and forwards it, untouched, to the network server, which owns the keys and decrypts it. That is why the gateway sits alone on VLAN 35 with a single job — reach The Things Stack on UDP 1700 — and why adding a hundred more probes across the grove changes nothing on the wire.
EU868 is legally limited to roughly 1% airtime per device. LoRaWAN is for small, infrequent readings — soil moisture, a tank level, a gate contact — not images or streaming. The farm camera in step 7 rides LTE for exactly this reason; only its sensor data would go over LoRa.
/ip route print resolves and it can reach only VLAN 35's gateway — not the office.09 · Step 4 of 8
600 m of line of sight, one VLAN trunk, no trench. A pair of 5 GHz dishes and MikroTik's nv2 protocol.
▲ Show step 4 in the interactive topology · select SXT pair for its config
# SXT-SHED (AP end). nv2 = MikroTik TDMA: scheduled slots beat 802.11 back-off over distance
/interface wireless set wlan1 mode=ap-bridge band=5ghz-a/n/ac channel-width=20mhz frequency=5500 \
ssid=farm-ptp wireless-protocol=nv2 nv2-security=enabled nv2-preshared-key="********" distance=1
# radio joins the bridge → the VLAN trunk rides the air
/interface bridge port add bridge=bridge interface=wlan1
# far end: same radio in station-bridge, its ether1 feeds a small switch
# controllers sit on V30 at the far end — untagged on their ports, tagged across the linkA point-to-point link is a cable you can't trench. The two SXT dishes are aimed at each other across the grove; nv2, MikroTik's TDMA protocol, replaces 802.11's listen-before-talk with scheduled time slots, which is what makes a long, one-to-one link stable where plain Wi-Fi would stall waiting for a faint, distant station. The link is a transparent bridge, so VLAN 30 (and management) crosses it exactly as if the greenhouses were in the shed — the controllers never know they are 600 m and one radio hop away.
5 GHz needs a clear Fresnel zone. An olive branch or a new polytunnel in the path drops the link from gigabit-class to nothing. It goes on the service-visit checklist next to the dish alignment — the same way the villa build checks its 60 GHz bridge for a growing tree.
/interface wireless monitor wlan1 at each end: connected, signal better than −65 dBm, nv2.10 · Step 5 of 8
The rule that matters: a device that moves water may reach its vendor and nothing else, and only the office may reach it.
▲ Show step 5 in the interactive topology · select R1 for its config
/interface list add name=WAN add name=MGMT /interface list member add list=MGMT interface=v99-mgmt /ip firewall address-list # egress pinned to the vendor by the rules below add list=VENDOR address=10.60.30.0/24 # input = TO the router; forward = THROUGH it. First match wins; the end drop = default-deny /ip firewall filter add chain=input action=accept connection-state=established,related,untracked add chain=input action=drop connection-state=invalid add chain=input action=accept protocol=icmp add chain=input action=accept in-interface-list=MGMT add chain=input action=accept in-interface=v35-lns protocol=udp dst-port=53,67 add chain=input action=accept in-interface=v30-control protocol=udp dst-port=53,67 add chain=input action=accept in-interface=v20-staff protocol=udp dst-port=53,67 add chain=input action=accept in-interface=v50-guest protocol=udp dst-port=53,67 # DEFAULT DENY: anything not accepted above is dropped add chain=input action=drop log=yes log-prefix=IN-DROP add chain=forward action=accept connection-state=established,related,untracked add chain=forward action=drop connection-state=invalid add chain=forward action=accept in-interface=v10-ops out-interface=v30-control comment="staff run the irrigation dashboards" add chain=forward action=accept in-interface=v10-ops out-interface=v40-cctv comment="staff view cameras" add chain=forward action=accept in-interface=v10-ops out-interface-list=WAN add chain=forward action=accept in-interface=v35-lns out-interface-list=WAN comment="gateway → The Things Stack only" add chain=forward action=accept in-interface=v30-control out-interface-list=WAN comment="controllers → their vendor cloud (DNS-pinned)" add chain=forward action=accept in-interface=v20-staff out-interface-list=WAN add chain=forward action=accept in-interface=v50-guest out-interface-list=WAN add chain=forward action=accept in-interface=v40-cctv out-interface-list=WAN comment="camera vendor cloud" add chain=forward action=accept in-interface-list=MGMT # default-deny: a PLC reaches the internet, never the office/cameras add chain=forward action=drop log=yes log-prefix=FWD-DROP
The forward chain reads as the policy matrix, line for line. OPS reaches the controllers, the cameras and the internet. CONTROL and LNS and CCTV each reach only the internet (to be narrowed to their vendor by DNS address-lists). STAFF and GUEST get the internet and nothing of the farm's. Everything else falls to the logged drop at the bottom. The single most important line is that last drop: without it, a compromised greenhouse PLC could scan straight into the office.
It is tempting to only stop things reaching the controllers. But a controller that can reach the whole internet is a foothold with an outbound channel. Pinning CONTROL and CCTV egress to their vendors' addresses (an address-list fed by DNS, as in the supermarket build) turns a compromised device from a pivot into a dead end.
FWD-DROP log shows attempts, so you can see what the design is turning away.11 · Step 6 of 8
The dish is the only way out. In bypass mode R1 owns the connection, and a DHCP script keeps the failover probe honest.
▲ Show step 6 in the interactive topology · select R1 for its config
/interface list member add list=WAN interface=ether1
/ip route
add dst-address=1.1.1.1/32 gateway=100.64.0.1 scope=10 comment="probe via starlink"
add dst-address=0.0.0.0/0 gateway=1.1.1.1 target-scope=11 check-gateway=ping distance=1 comment="main: starlink"
/ip dhcp-client add interface=ether1 add-default-route=no use-peer-dns=no comment="Starlink (bypass)" script={
:if ($bound=1) do={ /ip route set [find comment="probe via starlink"] gateway=$"gateway-address" }
}
# optional 4G at distance 2: used only when Starlink is down
/ip dhcp-client add interface=ether2 default-route-distance=2 use-peer-dns=no comment="4G backup"
/interface list member add list=WAN interface=ether2
/ip firewall nat add chain=srcnat action=masquerade out-interface-list=WANThis is the villa's Starlink pattern, and it earns its place again: in bypass mode the dish stops routing and R1 takes the carrier-NAT address directly, so the farm's firewall — not Starlink's box — is the edge. The recursive default route pings 1.1.1.1 through Starlink's gateway; a DHCP-client script rewrites that gateway whenever it changes, so check-gateway can tell a real outage from a reboot. The 4G line sits at distance 2 and only carries traffic when the dish is down — out here, that means a summer storm or the dish icing in the rare winter one.
/ip route print where comment~"probe" shows the same gateway as /ip dhcp-client print.12 · Step 7 of 8
A camera and a LoRa repeater on a gate with no power and no cable. The hard part isn't the config — it's the power budget.
▲ Show step 7 in the interactive topology · select Solar node for its config
# no mains, no cable: backhauls over its own LTE + WireGuard, and relays LoRa for the far grove/system identity set name=NODE-WEST # let it clock down: every watt is battery /system routerboard settings set cpu-frequency=auto /interface lte set lte1 apn-profiles=data /interface wireguard add name=wg-node listen-port=13232 /interface wireguard peers add interface=wg-node public-key="<hub public key>" endpoint-address=hub.example.net \ endpoint-port=51820 allowed-address=10.250.0.0/24 persistent-keepalive=25s /ip address add address=10.250.0.41/24 interface=wg-node # camera → NVR over the tunnel; LoRa → the same LNS as the shed gateway /iot lora servers add name=tts address=eu1.cloud.thethings.network up-port=1700 down-port=1700 /iot lora set lora0 servers=tts network=public # less logging = fewer writes = less power /system logging action set memory memory-lines=200 # watchdog reboots it on a wedge — nobody's driving out /system watchdog set watchdog-timer=yes
The node backhauls over its own LTE and dials a WireGuard tunnel home, so the camera reaches the shed NVR and the LoRa concentrator reaches the same network server as the shed gateway — all without a single cable leaving the gate. The config is deliberately frugal: the CPU clocks down, logging is trimmed to spare the flash, and the hardware watchdog reboots the board if a brownout wedges it, because the nearest pair of hands is 30 minutes away.
Add the loads: router + LTE ≈ 4 W, camera ≈ 3 W, concentrator ≈ 1 W → ~8 W, about 190 Wh/day. For four days of autonomy through cloud, at 50% usable depth of discharge, you need ≈ 190 × 4 ÷ 0.5 ≈ 1,500 Wh of battery — a 12 V / 130 Ah LiFePO4. The panel has to refill a day's draw in the worst month's few good hours: 190 Wh ÷ ~3.5 winter sun-hours ÷ 0.8 losses ≈ 70 W, so fit a 120 W panel and an MPPT controller for margin. Undersize either and the gate goes dark every January.
13 · Step 8 of 8
Nobody is on site. The network dials out, reports in, and backs itself up — over a tunnel, because both WANs are behind carrier NAT.
▲ Show step 8 in the interactive topology · select R1 for its config
/interface wireguard add name=wg-ops listen-port=13231
/interface wireguard peers add interface=wg-ops comment="operator hub" public-key="<hub public key>" \
endpoint-address=hub.example.net endpoint-port=51820 allowed-address=10.250.0.0/24 persistent-keepalive=25s
/ip address add address=10.250.0.31/24 interface=wg-ops
/interface list member add list=MGMT interface=wg-ops
/system logging action add name=hub target=remote remote=10.250.0.1
/system logging add topics=warning action=hub
# nightly export to the hub over the tunnel (no secrets)
/system scheduler add name=nightly-export start-time=03:00:00 interval=1d on-event={
/export file=r1-latest ; /tool fetch upload=yes url="sftp://10.250.0.1/backups/r1-latest.rsc" src-path=r1-latest.rsc
}
/tool netwatch add host=1.1.1.1 interval=30s type=simple down-script=":log warning \"Starlink DOWN\"" up-script=":log warning \"Starlink UP\""Both WANs are behind carrier NAT, so there is nothing to connect to — R1 and the solar node both dial out to the operator's hub over WireGuard and stay reachable there. Warnings stream to the hub's log server, a nightly export lands a config backup over the same tunnel, and netwatch turns a dropped dish into a log line the operator sees. When a controller or a node goes quiet, the operator knows before the grower does.
Starlink DOWN line reaches the hub over 4G within a minute.14
A farm network fails quietly — a dead probe, a dark camera, a greenhouse that stopped venting. Test the failures, not just the happy path.
| Test | Pass looks like |
|---|---|
| Sensor join | A probe power-cycled in the far grove rejoins (OTAA) and appears in The Things Stack within a minute. |
| Greenhouse isolation | From STAFF, nothing in VLAN 30 answers; from OPS, the dashboards load. |
| Controller egress | A packet capture shows a controller reaching only its vendor's addresses, not the open internet. |
| WAN failover | Dish unplugged: office stays online on 4G, sensors keep arriving, a log line reaches the hub. |
| Off-grid autonomy | Panel covered: the node runs past four days and the camera stays up. |
| Power return | Kill mains to the shed and restore it: every device comes back without a visit. |
15
What the network can't do on its own, and what covers each gap.
16
I test networks like this for a living. On a farm the prize is the things that move water and power — here's what I'd try, and why each stays bounded.
17
The routing, VLANs, firewall and WireGuard run on CHR. The radios, LoRa and solar don't — and that's the honest line.
| Runs in a lab | Doesn't — needs the real thing |
|---|---|
| R1's VLANs, DHCP, firewall and NAT on CHR; a second CHR as the operator hub with the WireGuard peer. | The LoRa concentrator and the EU868 radio — but The Things Stack has a free tier, and a single real gateway is cheap to test against it. |
| The failover logic: give CHR two upstream CHRs as "Starlink" and "4G" and pull one. | The nv2 point-to-point link and its distance behaviour — a bench pair of SXTs a few metres apart proves the config, not the range. |
| The policy matrix: prove each VLAN reaches only what the table allows. | The power budget — that's a spreadsheet and a clamp meter, not a simulator. |
18
Indicative EU street prices, late 2026, excluding VAT. Starlink hardware and subscription, and the sensors themselves, are separate.
| Item | Indicative (EUR, ex VAT) |
|---|---|
| R1 · RB5009UPr+S+IN | 260 – 320 |
| SW-SHED · CRS328-24P-4S+ | 440 – 560 |
| LoRa gateway · wAP LR8 kit | 160 – 220 |
| 2× SXT 5 ac (greenhouse PtP) | 160 – 220 |
| Greenhouse hAP ax + small switch | 180 – 260 |
| Solar node · LtAP LR8 LTE | 240 – 320, plus a data SIM |
| Solar kit · 120 W panel + MPPT + 130 Ah LiFePO4 + enclosure | 400 – 650 |
| Shed UPS 1,000 VA + surge protection | 200 – 350 |
| Network total | ≈ 2,000 – 3,000, plus cabling, the Starlink kit and the LoRa sensors |
Appendix
Most of this maps cleanly; two parts don't, and it's worth knowing which.
The shed router and switch become a Catalyst and an IR1101 industrial router (DIN-rail, wide temperature, built-in LTE) — the firewall is a zone-based policy, the VLANs and inter-VLAN routing are the same idea with different words. WireGuard becomes an IKEv2/FlexVPN tunnel dialled out to a hub, and the failover is IP SLA plus a tracked route instead of a recursive one.
LoRaWAN. Cisco's answer is its own IXM gateway and IoT platform, aimed at utilities and cities, not a six-greenhouse farm. In practice you run a third-party gateway to The Things Stack either way — the router just carries its UDP traffic.
The long-range bridge. There is no nv2. Cisco's Industrial Wireless / Catalyst IW radios do 802.11-based point-to-point well, but the TDMA-over-distance trick that makes a cheap SXT pair reliable at 600 m is MikroTik's. For one farm, the MikroTik radios are the right call; Cisco earns its place when a cooperative standardises across many sites.
Takeaways
Part of the Build series. See also: the holiday villa (Starlink, off-grid-ish), the festival (temporary, availability-first), and the supermarket (DNS-pinned egress).
I build networks for places the grid and the fibre don't reach: LoRaWAN for the sensors, long-range links to the greenhouses, Starlink for the world, and solar nodes where there's no power at all — all managed remotely so a problem is fixed before the crop notices.
Starlink & rural networks in Crete →