• 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