Sinks

what is a sink? a sink in factry historian is a mechanism for sending data (measurements, calculations, or events) to an external system this external system is an mqtt broker sinks are designed for use cases where you want to stream or publish live data out of the historian in a structured format , such as {{json}} or sparkplugb why does it matter? not all analytics, monitoring, or business intelligence happens inside factry historian many users need to integrate with iot or cloud services feed selected metrics into corporate dashboards share data with third party systems stream data into custom applications sinks allow you to publish relevant data , without exposing your entire historian or replicating the raw database how does it fit in the system? sinks operate as destinations , configured to push data to a specific broker each sink has a name (e g azure iot hub, or corporate mqtt broker) and an optional description a type , either generic mqtt, or sparkplugb generic mqtt the generic mqtt sink type can be used to send any message format over mqtt typically, this will be json the message format can be configured using forwarders docid\ td6emj3f 0xsgji7p4dag a sink of this type will additionally have a broker url and connection details (e g certificates, connection credentials) a qos setting optional buffer settings (in case the broker is unavailable) sparkplugb the sparkplugb sink type can be used to enforce the sparkplugb standard this can only be used to forward time series data in the form of measurements docid\ xqwlemdcnfff3 0h gmms or calculations docid\ opiodkgnngyjedx6zkg d a sink of this type will additionally have a broker url and connection details (e g certificates, connection credentials) a nodeid and a groupid a setting to configure the amount of metrics per message a setting to configure data only mode (where no birth or death messages are sent) optional buffer settings (in case the broker is unavailable) example you are operating a site where local users and systems need to share detailed process and energy data via an on site mqtt broker corporate needs only aggregated oee and energy data pushed to their cloud platform you configure two separate sinks a local mqtt sink , which will be used to send line1 speed, line1 temperature, line1 energy kw, etc all data is published in high frequency to the local broker a corporate mqtt sink , publishing only line1 energy kwh and line1 oee, once per day using events docid 0ith2zlcais5yywhsdtje data is published at a lower rate to reduce bandwidth and match what corporate cares about when you use it use a sink when you need to integrate historian data into a cloud or iiot platform you want to send only specific values, not full database exports the receiving system expects a specific protocol or message format you need to decouple storage from external consumption sinks are often used in hybrid setups where data stays on premise but select metrics are pushed to the cloud common misconceptions a sink is not a database replication tool it only sends specific, configured values, using forwarders docid\ td6emj3f 0xsgji7p4dag , not all measurements sinks are not meant for backups or historical data exports they are designed for live or near real time streaming best practices use clear and consistent naming for your sinks choose the sink type that best matches the receiving system test your sink with real data and monitor for delivery issues more information creating a sink docid\ y4kz8um7h731s4hdh0n1y