🧌 A tiny MonsterMQ is running on industrial panels!

It turns your existing panels to a MQTT enabled device!

MonsterMQ-Edge is a lightweight MQTT broker – the Docker image is just 36MB. I have poured it into a SIEMENS Industrial Edge App…

Here’s what it does on the panel:

  • πŸ‘‰ Connects to the WinCC Unified Runtime
  • πŸ‘‰ Configurable tag publishing with wildcard support
  • πŸ‘‰ Configurable from a central MonsterMQ dashboard
  • πŸ‘‰ Store and forward to other MQTT brokers
  • πŸ‘‰ Archive data to Postgres or MongoDB
  • πŸ‘‰ … more will come …

Btw.: you can do the same with the full version of MonsterMQ with WinCC Open Architecture or with WinCC Unified running on the PC.

πŸ”— monstermq.com πŸ”₯ SIEMENS

Disclaimer: experimental state. But it is cool to see a tiny Monster running on a SIEMENS Panel.

#MonsterMQ #WinCCUnified #EdgeComputing #MQTT #OpenSource

1777581226974
1777581227091
1777581227318
1777581227775
1777581227827
1777581227928

🧌 Weekend project: a lightweight MonsterMQ broker for the edge!

Built in Go, based on another open-source project (Mochi MQTT), implemented to expose the same GraphQL interface as the full MonsterMQ broker and having the same storage backend (SQLite, Postgres, MongoDB).

What does that mean in practice? You can run a lightweight MonsterMQ instance at the edge and monitor and configure it from the same MonsterMQ dashboard and having the data in the same storage format. No separate tooling needed.

Current state:

  • πŸ‘‰ Single binary 25M
  • πŸ‘‰ In memory last value storage
  • πŸ‘‰ Archiver for SQLite, PostgreSQL and MongoDB.
  • πŸ‘‰ MQTT Bridge available to pub/sub from/to other brokers.
  • πŸ‘‰ Backend storage options: SQLite, Postgres or MongoDB
  • πŸ‘‰ Same GraphQL interface – compatible with the existing dashboard

Very early stage, and just an experiment for now. What do you think about it?

πŸ”— monstermq.com

#MonsterMQ #MqttClaw #MQTT #Edge #EdgeComputing #Go

1777269439611
1777269439866
1777269440074

🧌 What has MonsterMQ become?

I started this as an open-source MQTT broker, to learn MQTT. But somewhere along the way it grew into something bigger…

Connectivity:
πŸ”„ MQTT Bridging
πŸ“¨ Kafka Bridging
πŸ”Œ OPC UA Client & Server
βš™οΈ PLC4X (PLC connectivity)
🏭 WinCC OA & WinCC Unified Clients
πŸš€ NATS Client & NATS Protocol Server

Processing & Transformation:
πŸ•ΈοΈ Neo4J integration
⚑ SparkplugB Decoder
πŸ”„ Workflows for data transformation
πŸ•ΈοΈ Clustered and distributed setup

Archiving & Storage:
πŸ’Ύ Last value storage: in-memory and databases, infinite retained messages
πŸ—„οΈ Internal database archiving: MongoDB, Postgres, Timescale, SQLite
❄️ Logging to QuestDB, MySQL, Postgres, Timescale, Snowflake

APIs & Interfaces:
πŸ” GraphQL
πŸ“‘ MQTT API
πŸ€– MCP Server
πŸ“Š Prometheus
🏭 i3x / CESMII
πŸ”œ REST API β€” coming soon!

An integrated topic browser, visualizer, and AI analyzer. πŸ’‘

πŸ‘‰ MonsterMQ.com

MQTT Broker with i3x? – MonsterMQ got it!


A i3x server integrated directly into MonsterMQ!

What’s happening under the hood:
πŸ‘‰ MQTT topics are stored in memory
πŸ‘‰ Historical values are persisted in MongoDB
Those features have been available in MonsterMQ for a long time…

The i3x interface just exposes all of that data via the i3x protocol!

πŸ’‘ This means you get a full MQTT broker with structured, queryable data access via i3x – all in one place.

WhatsApp messages from WinCC Unified

Someone asked me if it’s possible to send WhatsApp messages from WinCC Unified πŸ’¬

Yes, and it’s simple! A small Python helper connects to the GraphQL server of WinCC Unified, subscribes to a tag to get the message text, and forwards it to WhatsApp via Twilio. That’s it. And for sure, the same can be done with WinCC Open Architecture.

Available here: https://github.com/vogler75/winccua-twilio

πŸš€Β Nightly new Feature in MonsterMQ: OPC UA Server Connectivity!


With this integration, MonsterMQ can nowΒ connect directly to OPC UA ServersΒ and make the data available onΒ MQTT topicsΒ β€” bridging two key industrial protocols.

Plus we have integrated a topic tree browser, see pics!

I took a half day off work, to finish this.

πŸ”— https://monstermq.com – Open-Source πŸ‘
πŸ‘‰ Star it on GitHub if you like it!

✨ Having a REST and GraphQL API on the WinCC Unified Comfort Panel β€” it’s possible!

I recently started using my panel at home and felt lost without having such API’s. 

So I decided to change that:

βœ… I built a lightweight REST and a GraphQL server for WinCC Unified.

βœ… Implemented in Rust, they’re native, lightweight, single executables.

βœ… Low memory and CPU footprint – thanks to Rust!

βœ… With GraphQL, there is also support for tag & alarm subscriptions! πŸ”„

I always prefer using GraphQL β€” I find it tedious to constantly refer to separate REST documentation. But for some simple use cases, REST is perfectly fine.

Capturing WinCC Unified Traces to Elasticsearch

In industrial automation, logging and monitoring are crucial for maintaining system health and troubleshooting issues. Siemens WinCC Unified provides built-in tracing capabilities that. In this post I will show how to capture that traces to Elasticsearch to allow seamless log collection, storage, and visualization.

Step 1: Capturing WinCC Unified Traces

WinCC Unified provides a trace tool that simplifies the process of collecting traces. The tool allows logs to be written to files, which can then be read by Logstash (a tool to process log files).

In that example we will write the log files to C:\Tools\logstash-siemens\logs directory.

"C:\Program Files\Siemens\Automation\WinCCUnified\bin\RTILtraceTool.exe" -mode logger -path C:\Tools\logstash-siemens\logs

Step 2: Collecting Logs with Logstash

Create a Logstash configuration file (e.g.,Β C:\Tools\logstash-siemens\logstash.conf) with the following setup:

input {
  file {
    path => "C:/Tools/logstash-siemens/logs/*.log"  # Use forward slashes for Windows paths
    start_position => "beginning"
    sincedb_path => "C:/Tools/logstash-siemens/sincedb"  # Save the reading state
    codec => plain {
      charset => "UTF-8"
    }
  }
}

filter {
  # Drop empty lines
  if [message] =~ /^\s*$/ {
    drop { }
  }

  # Add a custom field to identify the log source
  mutate {
    add_field => { "Source" => "WinCC Unified" }
  }

  # Use dissect to parse the log format correctly
  dissect {
    mapping => {
      "message" => "%{#}|%{Host}|%{System}|%{Application}|%{Subsystem}|%{Module}|%{Severity}|%{Flags}|%{Timestamp}|%{Process/Thread}|%{Message}"
    }
	  remove_field => ["message"]
  }

  # Remove leading and trailing spaces
  mutate {
    strip => ["#", "Host", "System", "Application", "Subsystem", "Module", "Severity", "Flags", "Timestamp", "Process/Thread"]
  }

  # Convert timestamp to @Timestamp (ensure it matches your log format)
  date {
    match => ["Timestamp", "yyyy.MM.dd HH:mm:ss.SSS"]
    target => "@timestamp"
    timezone => "UTC"
    locale => "en"  # Add locale to avoid parsing issues due to different formats or locales
  }
}

output {
  # stdout {
  #   codec => json_lines
  # }

  # Elasticsearch output (uncomment to enable)
  elasticsearch {
     hosts => ["http://linux0:9200"] # Change it to your Elasticsearch host
     index => "wincc-traces-%{+YYYY.MM}"
     # user => "elastic"
     # password => "elastic"
  }
}

Start Logstash to collect log files. First, download Logstash (https://www.elastic.co/downloads/logstash) and extract it to C:\Tools.

Then, run the following command to start Logstash using the specified configuration file:

C:\Tools\logstash-8.17.3\bin\logstash.bat -f C:\Tools\logstash-siemens\logstash.conf

Forwarding Traces from WinCC Unified Panels


For WinCC Unified Panels, trace forwarding can be enabled, allowing traces to be captured with the WinCC Unified trace tool on a PC. The traces will then be also be written to files on the same PC (by the tool you started at Step 1).

“C:\Program Files\Siemens\Automation\WinCCUnified\bin\RTILtraceTool.exe” -mode receiver -host -tcp

Step 4: Visualizing Logs in Kibana

Once logs are stored in Elasticsearch, Kibana provides a powerful interface to explore and analyze them.

  1. Open Kibana and navigate toΒ Stack Management > Index Patterns.
  2. Create a new index pattern matchingΒ wincc-traces-*.
  3. UseΒ DiscoverΒ to explore logs and apply filters.
  4. Create dashboards and visualizations to monitor system health and performance.

MQTT Bandwidth Efficiency: The Role of Topic Alias in MQTT 5 and Why I Only Got It Working with EMQX?

Recently, I conducted a test to analyze the bandwidth usage of MQTT, and one feature stood out as particularly impactful: the Topic Alias feature in MQTT 5. This feature can significantly reduce the overhead associated with long topic names, which is especially relevant in UNS (Unified Namespace) implementations using ISA-95-style topics, where topic names tend to be lengthy and sometimes consume more bytes than the payload itself.

πŸ’΅ It can make an impact if you are being charged based on the amount of data transferred (cloud).

🚨 The Importance of Topic Alias

The Topic Alias feature allows a client to map a topic name to a shorter alias, reducing the amount of data transmitted. This can drastically lower bandwidth usage when transmitting messages with long topic names.

Using Topic Alias during publishing is straightforward but requires the topic-to-alias mapping logic to be implemented in the client program (which is not difficult to do).

On the subscriber side, the implementation should ideally be seamless. In theory, a subscriber needs only to set the maximum allowed alias number during the connection phase. This should make the feature easy to adopt for receiving applications.

πŸ‘‰ During my tests, I discovered something surprising: EMQX was the only broker (of the ones I have tested) to support Topic Alias for subscriptions(!) out of the box. With others I was unable to enable this functionality.

πŸ‘‰ To note: most articles about Topic Alias focus primarily on its use during publishing, not on subscriptions. I was focused on subscriptions.