Saw a great discussion comparing Ignition vs UMH in the context of Unified Namespace. In Ignition, you often script and store calc/static data (e.g. line metadata, last order) to support descriptive/functional/informative namespaces (à la Walker Reynolds). Curious how you'd best approach this in UMH: MQTT retain? Recalculate downstream? Store in Timescale? What’s considered best practice in the UMH world for this kind of contextual data?

My design isn’t following the same namespace strategy but for static info we need a database or other source, could be a file even. We subscribe to the relevant metadata and publish to MQTT under a relevant topic. For timeseries tags for example there is the “value” payload which changes regularly, and then another payload with the metadata for every tag which has things like the description, UOM, source system, anything else a consumer might need to know about that tag.

Yes, I did something similar to this too. Both storing data in NodeRed, Timescale and then query when needed. I'm trying to replicate the course materials now to actually have it all "in one place".

What do you mean by in one place?

The way this is described, is that you can access all information through a single source of information. In Ignition this is done by tag viewer where all the types of namespaces are stored. Some are updating continuously, others are information that rarely change. This is what I'm trying to achieve in the UMH stack too. Of course, I could say that TimescaleDB is that central source of Truth and we write everything there in a structured way. OR to use MQTT. That's basically my question, what to use for what best

I’m interested if anyone else has a suggestion but I think this is something like /value and /info in MQTT, I think with UMH this is a custom schema for the tag info and it would be the historian one if you want to store the values

Hey Luke, here’s my take on it: 1. Data Contracts for Functional vs. Informative - We use data contracts (like our _historian contract) to handle raw functional data, and then derive “informative” streams (e.g., _analytics or _OEE) from that. - That means you can have a _historian stream with the raw values, and then you create derived streams when needed—but we don’t strictly separate them because sometimes you’ll subscribe to an informative stream to do further aggregation. 2. OEE Calculation - Calculating OEE in real-time through a message broker is actually an anti-pattern. OEE is best processed as a batch because it needs to handle timeline corrections (e.g., if a shift is later classified as non-existent due to an operator’s absence). - In short, OEE should be computed in batch mode and stored (or re-computed) in a database like Timescale rather than relying on the broker. 3. Metadata Handling - For metadata, we recommend including a dedicated metadata field (an object with key/value pairs) in each _historian message. Later, when ingesting into Timescale, we de-duplicate this data to ensure a consistent reference set. 4. Last Order Data - As for last order, if you use a data contract like _analytics/orders/add, you can always look back in time via Kafka. This means the last order info is available as part of the stream, but for permanent storage and queries, you’d rely on Timescale. 5. No Single Source of Truth (Tech-wise) - There’s no one component that’s “the single source of truth” (i.e., it’s not just the broker or just the database). The UMH architecture combines multiple technologies: a broker for streaming and a persistent store (like Timescale) for historical data and reference info. Hope that clears it up!

Right! That makes sense. And perhaps if needed, republish latest values e.g. OEE to MQTT after processing to notify other systems if needed? Also regarding 3. metadata, do you refer to tag groups as described here? https://umh.docs.umh.app/docs/datacontracts/historian/

As i have done a long time is reading live data in nodered, same temporary data and calculate production rates with a moving average for the last 10 minutes. This value is saved to DB on every cycle along with some additional data from the machine. Main benefit with this is when displaying data on real time dashboards i only have to query a few values from the db instead of a complex aggregation.. I am however looking at changing this to only have rawdata in the db.. Maybe it could be a good way to add another schema in the DB for calculated data.

Simply put in the payload a meta data field, it is not deduplicated in timescale though

Yes, that is what i am migrating to with the new stack. I am doing a lot of rework and change of the data for better structure and performance.