- Communicator builds list of device controls (control templates)
 - Communicator syncs control list with messenger
 - device controls are paired with application controls based on endpoint and device control name
 - controls have default usertype, application panel controls may override this type

 - device commands can be tied to multiple device controls


 - Communicator receives a control update:
    - communicator looks up command for control template
    - device string is generated and sent

 - Communicator receives a device string:
    - device string is matched to command
    - control templates are looked up for command
    - command returns value for each control


  - Control sync process:
    - Communicator builds list of commands and a list of controls
    - Controls are synced with server
      - ncontrol requests list of server defined controls
            - server controls are matched with ncontrol templates based on ctid
        - "ctid" and _id are both key fields.  _id is the mongo document id,
         "ctid" is unique within the endpoint communicator instance and generated by the class definition
      - ncontrol adds missing control templates and updates server control_templates which do not match class
      definition
    -


   - CHanges from Devctrl-mysql:
     - control_template table dropped, fields moved to control objects



    - Control Updates:
        - not stored in database
        - value and source



   --- TCPCommunicator/Endpoint status management ---

 - Is endpoint enabled?  (Endpoint.enabled)
 - Is communicator connected to messenger? (Endpoint.communicatorConnected)
    - In lieu of communicatorRunning, which is unknowable without communicator connection
 - Is device reachable (ping)? (Endpoint.reachable)
 - Is device connection established? (Endpoint.connectionEstablished)
 - Can communicator log in to device? (Endpoint.loggedIn)
 - Is device responsive? (Endpoint.responsive)
    - Keep log of last communication, establish maximum time between communication