Raspberry Pi PLC Roadmap - MQTT, WebSocket and Alarms in ZPi v2

With ZPi Controller v1 wrapped up — the operator-facing ZView, MCP, Modbus and Programs — it became clear what belongs in v2. Here is the priority order and the reasoning behind it.

Priority 1: MQTT — Modbus alone is not enough

PLC MQTT integration is priority one. Modbus is a proven standard in industrial PLCs, but its bridge to the IoT ecosystem is weak. With MQTT you get:

• Home Assistant auto-discovery, so switches and sensors register themselves.
• Two-way integration with Node-RED, building flows without a line of code.
• Grafana visualisation (MQTT → InfluxDB → dashboard).
• Zero-configuration gateways to clouds such as AWS IoT, Azure IoT Hub and ThingsBoard.
• Peer-to-peer communication between multiple ZPi boards.

The design:

zpi/<deviceId>/io              → publish, 1Hz
zpi/<deviceId>/io/outputs/{i}  → publish on change
zpi/<deviceId>/cmd/output/{i}  → subscribe (toggled externally)
zpi/<deviceId>/cmd/data/{i}    → subscribe (write D[])
zpi/<deviceId>/event           → publish (rule fired / alarm)
zpi/<deviceId>/status          → LWT online/offline retain

MQTTnet covers both the client and the broker on the .NET side. Roughly three days of work.

Priority 2: WebSocket — what a live monitor should mean

A WebSocket live monitor comes second. The monitor page currently polls /api/io at 1Hz. That is a one-second lag on an input change plus wasted polling traffic. Switching to WebSocket push brings the response under 50ms.

ZView can use it too: subscribing over WS instead of polling /api/io cuts the CPU load substantially.

Roughly two days of work.

Priority 3: alarms and notifications — the key to unattended operation

PLC alarm notifications mean adding a “notify” action to the rule engine cards:

• Telegram bot (the most immediate)
• Slack incoming webhook
• Email (SMTP)
• Generic webhook (integration with other systems)

# example rule card
Trigger: OnInputRising IN[0]   (emergency stop input)
Action:  AlarmSend "🚨 비상정지 발생 - LINE2 컨베이어" → Telegram + Slack

Essential for unattended night shifts and remote monitoring. Roughly one to two days of work.

Nice-to-have features next

The ZView roadmap

The ZView roadmap is separate because it was the most interesting part of v1.

The biggest challenge — resolving user program mode conflicts

User program GPIO conflicts are the biggest challenge. Today, when a user program on the Programs page takes over the GPIO, the rule engine and ZView stop automatically. Things to solve in v2:

• If a program exposes its own HTTP API, ZView should analyse it and adapt.
• A program declares its control points through a manifest (program.json):

  {
    "controlPoints": [
      { "label": "펌프 시작", "endpoint": "POST /pump/on" },
      { "label": "비상정지", "endpoint": "POST /pump/estop", "danger": true }
    ]
  }

  The AI reads the manifest and generates the ZView automatically.

This is an architectural decision rather than a simple feature addition, which makes it the first job in v2.

Cost and feature comparison — Mitsubishi and Siemens PLCs

Where ZPi sits: the space where a PLC was too expensive or too closed to use at all — education, R&D, makers, small OEMs and IoT gateways.

A proposed order of work for v2

Week 1: Backup / rollback cleanup (done)
Week 2: MQTT integration + Home Assistant auto-discovery
Week 3: WebSocket + live monitor improvements + multi-slot ZView
Week 4: Alarms + Telegram/Slack
Week 5: Local history DB + Grafana integration guide
Week 6: User program manifest + AI ZView generation v2

One last thought — AI-friendly infrastructure

AI-friendly infrastructure is the perspective we learned most from building ZPi Controller v1: a tool description that becomes the behavioural guide for an LLM, a server that fills in the infrastructure around what the AI produced, and a system that recovers automatically from a user configuration mistake.

That design pattern applies outside ZPi as well — internal back-office tools, data dashboards, operator UIs for IoT devices.

v2 goes the same direction: simpler, safer, and easier for an AI to work with.

MQTT, WebSocket and alarms are the top three for v2, and widening that AI-friendly infrastructure on top of them is where ZPi Controller is going.

Feedback and collaboration

If this post gave you any of the following, we would like to hear from you:

• Feature suggestions.
• An interest in trying the board yourself (hardware sample or demo).
• Ideas for other industrial domains such as semiconductors, pharmaceuticals or food.
• A wish to see the code (we can let you know when it is open sourced).

You are welcome to reach us through our contact page or by email.

Series wrap-up

That is all seven parts of the ZPi Controller series.

1. Building a PLC on a Raspberry Pi — introducing ZPi Controller
2. ZView: an industrial HMI written by AI in plain language
3. Claude Desktop MCP — the grind behind a one-double-click installer
4. Three gotchas we debugged — Modbus port, mDNS cache, Regex $1
5. Raspberry Pi WiFi resilience and boot time from 1 min 31 s to 33 s
6. (this post) The v2 roadmap
7. A ZView sample — a Modbus IO monitoring screen in a single page

Thank you for reading.

Contact

• Email: [email protected]
• Instagram: https://www.instagram.com/going.sen/
• Website: https://intosen.com/kr/consult/