Generic adapter
How to use generic adapter to register data through mqtt.
Overview
Generic adapter allows to register 3 types of data:
- production data - message consists quantity of good parts
- scrap data - message contains quantity of scrap parts as well as optional scrap reason
- downtime data - message contains reason of current downtime
All messages for this adapter are in JSON format.
Stations are recognised based on channes as described in stations configuration
Production data
Production data messages are reported to channel ending with /production. For example such channel may be vendor/company/line/station/production
Message consists of one key value, example message:
{ "value": 10 }
Causes system to recognise 10 good parts.
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.