Generic adapter
How to use generic adapter to register data through mqtt.
Overview
Generic adapter allows to register 3 types of data:
- production - message contains information about a quantity of produced good parts as well as an optional product
- scrap - message contains information about a quantity produced bad parts as well as an optional scrap reason
- downtime - message contains information about a reason of a downtime
All messages for this adapter are in JSON format.
Stations are recognised based on channels as described in stations configuration
Production
Production messages are reported to channel ending with /production, for example vendor/company/line1/station1/production
Below there are examples of different payloads accepted by the generic adapter.
- Most basic information - only quantity is provided
{ "value": 10 }
- Payload with an optional timestamp value provided.
{ "timestamp": "2025-01-31T00:00:00Z", "value": 10 }
- Payload with an optional product value provided.
{ "value": 10, "product": "product1" }
- Payload with optional product and cycle time values provided.
{ "value": 10, "product": "product1", "cycle_time": 60 }
- Full payload example.
{ "timestamp": "2025-01-31T00:00:00Z", "value": 10, "product": "product1", "cycle_time": 60 }
Basic payload
Scrap data
Scrap data messages are reported to channel ending with /scrap. For example such channel may be vendor/company/line/station/scrap
Message consists of keys:
value- describes number of scrap parts (required)reason- described scrap reason
example message:
{ "value": 10 }
Causes system to recognise 10 scrap parts without reason.
{ "value": 10, "reason": "malfunction" }
Causes system to recognise 10 scrap parts with reason malfunction.
reason field should be simple yet unique for all reasons. It must consist of only letters, numbers and _.
This field is used only to recognise reason in mqtt system. Later user can define human friendly name and symbol.
How scrap reason is persisted?
In system there is dictionary based scrap reason management, that allows advanced reporting such as pareto reports.
Each scrap reason has network tag field that must match value coming in reason key.
Additionaly each scrap reason has human friendly name and symbol. When scrap reason with matching network tag is not found it is created: name and symbol are based on network tag.
Then user should change name and symbol to more precise and human friendly description.
Downtime data
Downtime data messages are reported to channel ending with /downtime. For example such channel may be vendor/company/line/station/scrap
Message consists key reason that describes downtime reason
example message:
{ "reason": "lunch" }
Causes system to start downtime with this reason or assign it to current downtime.
reason field should be simple yet unique for all reasons. It must consist of only letters, numbers and _.
This field is used only to recognise reason in mqtt system. Later user can define human friendly name and symbol.
If current downtime has other reason than in message, current downtime is paused and new one with reason from message is started.
How downtime reason is persisted?
In system there is dictionary based downtime reason management, that allows advanced reporting such as pareto reports.
Each downtime reason has network tag field that must match value coming in reason key.
Additionaly each downtime reason has human friendly name and symbol. When downtime reason with matching network tag is not found it is created: name and symbol are based on network tag.
Then user should change name and symbol to more precise and human friendly description.