Hermes Command via RESTful API (Third Party Device/System SMEMA Interlocking)

[Industry4]

( This issues covers work for #76 and elements of #17 )

Following on the implementation of Hermes Command #22 the request is to control the Command Interlock via a RESTful API.

Use case

• A Third Party System or Device needs to either preform a physical Action or check the Hermes Data.

Operation

• REST API to Unblock/Block the Interlock (similar to https://github.com/Industry4/MultiPlug.Ext.SMEMA/wiki/REST-API)
• REST API to Enable/Disable Latching ("Ignore Once" in the terminology of the Hermes Command when Latching is Disable)
• System Start-up state of the Interlock - Blocked/Unblocked/Latched/Unlatched (Clone MultiPlug.Ext.SMEMA)
• MultiPlug Events to also control the Interlock (Clone of MultiPlug.Ext.SMEMA)
• Blocking and Unblocking MultiPlug Events (Clone of MultiPlug.Ext.SMEMA)
• Changing the Value of 'Failed Board' value of the Hermes Standard
• Optional: Rejecting the current product and asking the operator to remove it from the Equipment

See: MultiPlug.Ext.SMEMA

• MultiPlug.Ext.SMEMA implements SMEMA Interlock control via Third Party control ( Control the Interlock via MultiPlug Events MultiPlug.Ext.SMEMA#1)
• Remote Downstream Interlocking (Upgrade path from MultiPlug.Ext.SMEMA) #76 Request a migration path from users who are also controlling the Interlock via REST and MultiPlug Events

Consider

• Recipe Verification (Auto and Manual Product Changeover) #84 Would allow Verification to occur on the Upstream side of the Equipment, but wouldn't allow Interlocking to Occur on the Downstream (When the product is in the Equipment) - It also doesn't have a native REST interface and only works with MultiPlug Events (Used for Serial Port control)