How to start with a Unified Namespace: follow one signal
Start a Unified Namespace (UNS) with one useful measurement. Make its meaning clear, keep its history, and let another application use it. Watch the OpenHub demo on YouTube (3 min 46 sec).
A furnace temperature appears on a screen. The value updates and the chart moves. Then someone needs the last ten minutes for a report, and another application wants the same measurements.
That is a practical starting point for a UNS. Take one signal with a purpose and follow it beyond its first chart. Here we use a fictional furnace zone, like the simulated equipment in the OpenHub demo.
First, agree on what the measurement describes. Zone temperature and material temperature can both be expressed in degrees Celsius, but they are different facts. Identify the zone, unit, measurement time, and responsible source so another consumer can interpret the value without reading the producer's code.
Use the same measurement in different ways
A service reacting to new readings can subscribe through MQTT. A reporting application may instead request a time range through an API. In OpenHub, UNS API Global provides authenticated access to current values, history, and aggregates.
The latest known value still needs a timestamp. A reading from twenty minutes ago should not look current if the source normally updates every few seconds. Historical queries answer a different question: how did the value change over the selected period?
For more exploratory work, an analyst can query archived measurements directly in QuestDB using SQL. OpenHub's Explore view can show and copy SQL behind supported historical views. Direct queries require knowledge of the stored tables and separately configured database access; Controller permissions do not automatically carry over.
Make a richer result reusable
Suppose the report later needs temperatures during a particular production order. A custom service could combine archived measurements with order details from another system, matching the equipment and time window. Using only the equipment's current order could wrongly attach yesterday's readings to today's work.
That service can register a Data Catalog offer in the OpenHub Runtime preview. Users can find its description, parameters, and response schema, then try the endpoint with their credentials. The service performs the queries and enrichment; the catalog makes the result discoverable and reusable.
This is a possible extension of the example, not a report already shown in the video. It also illustrates why every external record need not be copied into MQTT: a prepared service can bring together the sources needed for a specific question.
Try the first data flow in UNS OpenHub
The demo video shows deployment of the Archiver and API services, setup of the hot-rolling simulator, and exploration of furnace measurements and history. The simulator produces fictional data; UNS Archiver persists eligible measurements to QuestDB. The integrated Runtime is in private preview, with requirements in the current quickstart.
After following the video, retrieve one historical window from another client and compare its times, units, and aggregation with Explore. This small check demonstrates whether a second consumer can use the data without changing its producer.
The same exercise could start with room temperature in a museum or water level in a tank. Start where someone needs the information. Expand when another consumer can find it, understand it, and put it to use.